[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SQL Backend

Hello Predrag, others...

I've just started following this thread, but I have a few things to
point out when looking at the LDAP standards and how they can be
implemented with an RDBMS back-end.

First, there's the issue with the schema.  With pure RDBMS systems, per
1NF you can't use repeating groups (multivalued attributes).  You would
basically create new tables and columns in the database to get around
this.  Some object-relational database systems get around this by
offering arrays (postgresql, for example), but support for arrays is
usually weak as they don't fit well in the relational model.

With LDAPv2, this isn't too bad, since if you have your schema defined
properly, you can probably create the necessary tables.

With LDAPv3, this gets more complicated, as extensible objects become
available which can contain any attribute/value pairs.  This allows
developers to use the directory for arbitrary configuration and
preference storage without having to change the schema each time.

The only way I can think of to get around this is to create a simple
table with the keys "dn","type","value".  The DN key would be either a
key into a DN table or the DN itself.  The "type" key would be the
attribute name, and the "value" key would contain the value.

This structure, however, is not a very good use of a RDBMS and would be
less efficient than using a B-TREE.  Some OODBMS systems can get around
this issue, but then we wouldn't be looking at the "least common
denominator" that works with everyone's database.

Another issue is what to do with binary values.  BLOBS are supported
differently by different database systems.  Some of the ones listed in
previous posts do not even support BLOBS in a usable manner.

For these reasons, I think that the best way to handle individual needs
for RDBMS backends for SLAPD would be to keep the back-end open with an
API and let individuals who really feel RDBMS is necessary work on
that.  I don't think that RDBMS support should be part of the OpenLDAP
core project when Sleepycat DB2 and other back-ends give the required
performance and stability.

Just my thoughts...