Re: SQL Backend

[Jauder Ho <jauderho@transmeta.com>]

Morning Clayton,
	
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
ldap server. 


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?

--Jauder


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