Re: db/schemas best practice

[Peter Marschall <peter@adpm.de>]

Hi,

On Tuesday 13 May 2003 15:19, Michael Engelhart wrote:
> 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 may be wrong but I think there have been problems with multiple suffixes 
for one backend.
IIRC currently there is a 1:1 required.


> 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?
Why so complicated ?
Use one suffix as a common base for all customers.
Now, when a new customer comes, simply create a new branch below
that base
Something like:
   + o=Customers
        + ou=Cusomer1
        + ou=Customer2         

> 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.
Because there is a simpler way without editing slapd.conf or restarting slapd.

> 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.

LDAP shares a common schema for a DIT (directory information tree).
There's no way around this.

The schema only tells what is allowed; the objects themselves can be
very different (different objectclasses, different attributes, ...)

Adding attributes to a self-defined objectclass is now problem in OpenLDAP.
All you have to do is update the schema files in the configuration and restart
the server.
The old custmers can use the new attributes if they want to, but if they don't
there is now difference for them. The same holds for new objectclasses.

Of course, you cannot have the same name for different attributes or 
objectclasses ;-)

Peter

-- 
Peter Marschall
eMail: peter@adpm.de