Re: RDBMS Backends & is ldap appropriate

[Clayton Donley <donley@wwa.com>]

Hi Folks,

I've been thinking a lot about these two subjects lately and thought I'd
share a few thoughts.

First, Giovanni Baruzzi brought up the following criteria for LDAP being
appropriate:

> 1. Searches outnumber the updates by 90 to 10
> 2. Reference information ist stored and not the actual
> Documents/Information
> 3. you must define only a small number of customized objects to meet your
> scope

I think the first two are very dependent on the back-end store being
used and not the protocol. The third point makes sense in most cases,
but may not be your decision point being that using a database would
require the same custom/proprietary schema.

I'm thinking that a better criteria would be to look at what LDAP still
lacks if you plan to do modification. In my mind, the biggest component
that the current protocol lacks from a modify perspective is support for
transactions. Most performance issues are not LDAP problems, but vendor
specific back-end issues.

As for RDBMS as a back-end, there is very little reason why an RDBMS
back-end WOULDN'T be suitable compared to BDB2 or other similar physical
datastores. After all, BDB2 doesn't partition data based on location in
the DIT or anything special. Just because it uses a tree structure to
index information doesn't imply that it matches the directory tree. In
fact, I haven't really seen anyone try to follow the DIT exactly since
older versions of QUIPU and some X.500 implementations that hashed the
entries at each level in the tree. For scalability and performance, you
pretty much need some DBMS functionality and from what I've heard, this
is the kind of functionality that people like Netscape have been adding
to their backends.

The only big issue I've seen with using an RDBMS as a back-end is
multi-valued attributes, which don't really fit the relational model.
However, you can simply normalize these multi-valued attributes in the
same way you would for fields in a database that have the potential for
multiple values -- break them into another table. Either way, this is
all done behind the scenes by the vendor from what I've seen, so it
really is a non-issue from an administrator, application developer, and
user standpoint.

The simple fact is that most directories are built on database
technology and most databases are adding directory access technology.
The actual line between database and directory seems to differ based on
the phase of the moon and planetary alignments. I would expect the line
to continue to fade over time as these technologies continue to
converge.

Here are some thoughts as to when NOT to use LDAP:
 - You need transactions
 - You need to generate complex reports (this is not LDAP's strength)
 - Your objects don't fit at all into standard schema (though this
    one isn't a showstopper)

With some servers, these may also be issues, but they are not completely
related to LDAP:
 - You need to maintain relational integrity (although I've heard that
    some LDAP servers can do this)

Hmm...That's all I can think of at this time. I'm sure I'm missing a few
things, but this ought to be enough to spur some discussion.

What do the rest of you think?

Clayton