Jesse W. Asher (jasher1@tampabay.rr.com) wrote:
Also, don't get confused with LDAP as a protocol and LDAP as a data
store. You can store your data in whatever, wherever, and however you
like and still deliver it via LDAP. That was exactly the point. A
lot of people tend to view LDAP as a data store and that is not what
LDAP is all about. LDAP is mostly about data delivery - not data
storage. A prime example of this is Netscape's directory server which
used to (I'm not sure if they still do) use Sybase as the data
repository.
All of the Netscape, iPlanet and Sun ONE family of servers use
Berkeley DB. The directory server products used to include a database
plug-in that would allow you to alternatively choose your own data
store. Not anymore - Now you have to write your own plug-in.
The reason for using Berkeley DB is that it is designed for
programmers, not database administrators. You don't have to waste
time thinking about things like 3rd normal form, primary keys, this
table and that field. It is a simple, robust software that can
handle up to 256TB databases, has been around since 1991 and it's
basically maintenance free. LDAP is not a relational system and
does not need a relational database backend.
You're absolutely correct on both counts. The issue is, again, that most
companies DO need a relational database because they have a LOT more data
than what usually goes into an LDAP server. Rather than maintaining data
in two places, it would be wise to maintain it in one place and have the LDAP
server interact with the database server to deliver its data. That's why
it is useful to have an LDAP server be able to use a database server as a
backend.