[Date Prev][Date Next]
Re: db/schemas best practice
I would use a relational database for this. LDAP doesn't seem
On Tue, 2003-05-13 at 08:19, Michael Engelhart wrote:
> Hello -
> In the FAQ-omatic, there's a post regarding having multiple databases
> with the following quote:
> "SLAPD can be configured to support multiple databases and each
> database can support multiple suffixes. The multiple databases each
> with a single suffix approach is preferred over the single database
> with multiple suffix approach. "
> I am developing something which stores contact data for multiple
> 'clients' (i.e., discrete businesses).
> My theory based on the FAQ response is to partition off each client, I
> could create a separate bdb backend config in slapd.conf and each time
> a client is added, add this and restart the server. Is this a
> reasonable approach?
> There is the headache of manually editing slapd.conf each time a client
> is created but besides that is there any thing "wrong" with handling it
> this way.
> My 2 questions assuming this is OK are:
> 1) How many backends can slapd deal with before needing to move to a
> new process or server (none of these clients will have more than
> probably 10,000 entries).
> 2) Some of the clients have custom attributes they want to have in
> there like for example and auto dealer may want to have a vehicleMake,
> vehicleModel and vehicleYear attributes so they can have that
> information associated with their customers entry. What I have
> currently is a schema that is shared by these backends and this seems
> to work fine. But if/when a new client comes on and I need to add an
> attribute, does this "break" existing clients data? The existing
> clients wouldn't be accessing or using these new attributes. Or do I
> have to dump and restore every backend when I make a change like that.
> Would a better approach be to have a schema for each client that needs
> new entries. The schema attributes are "generally" industry related
> so if I have 10 auto dealers, they'll all basically have the same
> requirements so they can be shared to some extent.
> Any advice is appreciated.