RE: db/schemas best practice

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Peter Marschall

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

In back-bdb this is now required by default, yes. You can change a #define
and rebuild to get the old behavior back, but you will lose performance by
doing so.

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

Right again.

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

There is no problem with adding new schema to existing databases. You can
always create new definitions, without impacting any existing information.
You cannot change existing definitions though.

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

The X.500 information model allows any entry to be governed by different
schema from any other entry. The fact that familiar LDAP servers don't
implement this feature makes it somewhat of a moot point, but real X.500
servers certainly handle this. It is possible for the current OpenLDAP design
to handle different schema per backend, but no one has been interested in
implementing this. For the most part, hiding custom schema within one portion
of the DIT, rather than publishing it across the entire server, just hinders
interoperability.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support