Re: RDBMS Backends & is ldap appropriate

[Giovanni Baruzzi <giovanni.baruzzi@allianz-leben.de>]

You are right, we can then implement the list as follows:

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

4. you shall not need relational integrity across updates involving multiple
objects
5. you don't need table oriented process (reports) (Oct 1999)

Only point 4 is not a performance and implementation issue but a protocol
characteristic.
Point 3 is just a suggestion, but not a limit.

I believe that TODAY these point are reasonable; if 4 is implemented in the
protocol we may see the birth of a "Object Oriented Database Access Protocol";
this wouldn't surprise me.

Bye
Giovanni



Clayton Donley wrote:

> 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