LDAP is NOT a Database!
by Brian K. Jones
* The "D" in "LDAP" stands for "directory", not "database"
* The "P" in "LDAP" clearly indicates that LDAP is, in fact, a "protocol".
* LDAP has no notion of rows, tables, or other database elements.
* LDAP has no notion of relational integrity (ie, foreign keys)
* SQL is useless when run against an LDAP server.
* LDAP data is a hierarchical collection of objects, not a linked collection of relations.
* There are no cascading deletes.
* You cannot write a stored procedure or trigger to help maintain LDAP data.
* Attributes of a given LDAP element can essentially be infinitely multi-valued without penalty.
* Individual attributes can be restricted in LDAP. You cannot do the equivalent (restricting access to a single field) in a database (to my knowledge. Post links if that's wrong).
* LDAP, as a general rule, uses standardized schemas to describe objects. I have not seen a standardized database schema. Ever.
* LDAP objects and attributes are defined using ASN.1 syntax. Similar to SNMP (another protocol), and not similar to a database.
* Your email client is probably ready and willing to look at an LDAP directory to autopopulate its addressbook data. To my knowledge, the same cannot be said of a database.
* You can put "ldap" in your nsswitch.conf file. You can't put "mysql".
* Two words: "spin lock"
There are plenty of other examples to point to here. Also note that I'm not saying that things are technically impossible. You could probably develop standard data schemas for mysql, and then develop an nss_mysql module for your systems to use. However, this would not make LDAP any more similar to a database.
It looks like you have proven that LDAP is not a *relational* database, but it's a hierarchal and traversable data store nonetheless.
It seems to me that LDAP isn't a database in the same way that SQL isn't a database. (I know, SQL is a language and LDAP is a protocol, but still). LDAP servers are implemented as data stores though. They are LDAP databases in the same sense that Oracle is an SQL database. Which of course is a matter of perspective.
|Yes, I was referring specifically to *relational* databases in the article, because when someone who knows nothing about LDAP hears someone they think has more experience say it's a database, that's what the newbie thinks. It is this kind of confusion I'm hoping to clear up. If I've enlightened only one person, maybe they'll explain it right to 3 newbies... and so on...|
Always google before you blog. :)
|OK, now that you've admitted that it is misleading, are you going to change it clarify what you really meant or just leave it in place as a testament to something unflattering? For its constrained application domain, the X.500 Data Model as required by the LDAP Standards has proven to lead to a very useful and powerful database as implemented by many vendors (including Oracle using their Relational Database as a lower level data store, IBM Websphere was smarter and used OpenLDAP itself for its directory and if they ever update to current technology they'll improve performance many-fold).|
LDAP *is* a database by any reasonable definition.
|I tend to think of LDAP as a facet or structured view of data stored in a database, much in the same way that the RDF and other metadata is related to that data in the tables and fields.|
|I see two relevant points in the comments above: LDAP is a database, but not a relational database, and to a great many people who use the term, 'database' is now considered synonymous with 'relational database'. '0_o' has suggested that this is a problem, and I would concur, but it seems to me that if one is going to go to the trouble of shouting something from the hilltops, it might be better to shout the broader concept that "lots of databases aren't relational". I say this with full awareness that if I had seen a blog entry with such a title, I would not have followed the link, so I know that 0_o's position is not without merit....|