I’ve seen people describe LDAP as being a database enough times to get really annoyed, and finally, to blog about it. So here, in no particular order, are all of the reasons why LDAP is not a database (er, that I can think of):

* 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.