Re: Relational database as backend?

[Simon Spero <ses@tipper.oit.unc.edu>]

I've been working on building an RDBMS/LDAP bridge, and as people have been saying,
it's a real head-twisting operation, especially since I've been spoiled by ODBMSs for
so long .   However, it is possible to get pretty good performance as long as you try
and optimise operations on the LDAP side as well as the RDBMS side. I could rant for
days on this,but I need more coffee first - Briefly, here are the major areas of
concern:

 1) "Storing objects in a relational database is like driving your car home from work
and disassembling it to put it in the garage" - old ODBMS saw. The models are
different, and this is one of those jobs that needs gallons of digital astroglide.

2) Different Object Classes can match the same query. Objects can have multiple
disjoint object classes.    You need to have a different result set for each possible
combination of  classes, unless you're willing to do more work in the bridge to
reassemble objects. . This can be heavily optimised, especially if there is only one
available object class, or if the LDAP server can compute object classes based on
search criteria or requested attributes. Much of the work can be done on the server
using various extensions to SQL.

3) RDBMS don't have multi-valued attributes; you need a whole new table, and possibly
a whole new result set for you to do your own joins on.

4) Extensible objects don't fit into any regular table - you need an extension table
with text attributes and values. This is ok as long as the attributes can't have the
same name as fixed attributes - otherwise all searches need to hit the extension table
just in case..

5) The ldap directory model is hierachical; RDBMSs aren't. Depending on whether you
can add extra fields and tables or not, there are several different mechanisms that
can be used concurrently to handle this. IF you can't add fields, then you can map the
DN into an additional query constraint based on its components. This supports BASE and
SUBTREE, but not ONE-LEVEL searching. efficient base and sub-tree searching can be
provided by adding a DN table and field, using exact match and right truncation.
one-level can be provided less efficiently by doing substring searches. efficient
one-level searching can be provided by adding a parent field referencing the DN-id of
the parent.

6) updates and adds need to be routed to the appropriate combination of tables. Some
tables may be read only

Simon