Re: LDAP vs. SQL

[kloecker@springer.de (Jens Klöcker)]

=======> On 2000-10-11, sj2  <sj2> wrote:

    sj2> I am designing a web-site for my company. Its will have
    sj2> technical articles, mailing lists, web-based mail,
    sj2> newsgroups, FAQs, user profiles etc.

    sj2> I want to map the entire site structure on a LDAP server and
    sj2> use the LDAP server as my information storage backend. My
    sj2> boss says we should go with a Relational Database and that a
    sj2> LDAP server is an un-necessary layer.

That's exactly what we discussed some time ago in one of the projects
I'm involved. The problem was to design a flexible and fast system for
reference linking in HTML online articles, where the reference
sections as well as their digital IDs (like DOI or PubMed IDs) must be
hold for fast on-the-fly rendering.

I tried to answer the following questions:

1. Has the information to be stored an implicit or explicit tree like
   structure?
2. Is fast read access more important than write and update
   operations?
3. Is it necessary to distribute or replicate the database?

For our reference IDs I could answer "yes" to all three questions, the
reference sections failed the test. Hence, I used a _mixed approach_
and stored the reference sections as XML in a relational database,
together with DNs as "fast pointers" to the LDAP, where we hold the
reference IDs.

This mixed solution has proofed as stable, fast, and very flexible. It
works for a huge amount of data (the LDAP part holds more than 100.000
entries) and the additional complexity added is (thanks to DBI and
PerLDAP) fairly small.

Maybe that helps you to make a decision.

Cheers,

-- 
Jens Klöcker, Springer-Verlag Heidelberg | LET X = X.