[Date Prev][Date Next]
Re: SQL Backend
I think your suggestion that a simple "dn","type","value" would work
initially. We could get creative later. (note: just cleaning up my
postponed messages). What I have been suggesting is that we have a master
"feeder" backend ldap server that then replicates to a master frontend
various sources<---->"feeder"<--->"frontend"<---> second level
this way the feeder can be slow while keeping the frontend fast except
when reindexing. anyone know if we can reindex offline?
On Wed, 9 Sep 1998, Clayton Donley wrote:
> 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...