RE: [PHP-GENERAL] LDAP

> my group among many others. But in fact, there are very few > things you > can do with it that you can not do with other tools such as MySQL. It really comes down to using the right tool for the right job. Many vendors are writing products that store profiles and user auth in LDAP for quick lookup, and most commercial browsers/email programs will lookup users (phone book/address book services) against LDAP, but most will not against SQL. Also, LDAP is a standard - both the protocol and some common schema are defined. SQL's biggest problem when used as a shared directory service is that there are so many flavors that beyond very simple usage, you have to know which SQL server you use - is it mySQL, Informix, Oracle? Each does things different ways. However, there is a lot to be said for using what you know. If you are building a web app with some users and passwords, and know SQL better, use SQL. If you are building an enterprise with lots of services you want to integrate users across, and may be tying in commercial products, consider LDAP (actually, consider what the products you want to integrate support). If you integrate against Windows 2000, you will almost be guaranteed to need to deal with LDAP at some point (not sure if that is a plus or minus for LDAP :-) ), and given this, you can expect a lot of vendors to write apps that plug into Active Directories via LDAP... > People might use it because they are not aware of other tools, or they > are familiar with X.500 and want to stick with a data structure they > already know, its data structure is suited to a particular > problem they > are attacking, or they are mandated to use it, or ... [fill in the > blank]. There is no special magic about it, really... I'd say "it is suited to a particular problem" is probably the best answer for properly deployed LDAP services. Relational databases and LDAP directories fill different, complementary niches. You can use either for any database purpose, but I'd far rather use LDAP for authentication and user profile management, address book lookups, etc. At the same time, I would never use LDAP to backend a knowledge base, online store transaction database (though the catalog may be appropriate for LDAP), or other services with high volumes of writes. It's certainly not reasonable to dismiss it as some "left over from the Titanic-like wreck of ISO/OSI" without properly understanding its place in the world :) 'Course, in the end, what you use comes down to what best solves your problem. -Jeff