I've just started working on an existing application that uses an LDAP directory service as its object store instead of a database. Many of my coworkers have been commenting how an application should never use a directory service instead of a database as its object store. I've got to work on it regardless, and won't be able to change it from LDAP to a database anytime soon.That said, my coworkers comments brings up the question in my mind: Why is it bad to use a directory provider instead of a database as an object store? Could there ever be cases where this would not only acceptable, but even better than using a database?
Using a Directory Service instead of a Database
design;database
I also use Active Directory on my corporate website. One of the benefits was that not only our staff shared for the website the same account they use to connect to Windows, but also customers themselves could seamlessly use different services outside the website itself (like be able to connect to some of our servers through Remote Desktop or use SVN, which relies on Active Directory).Having a single source of truth is always nice, including for user accounts. I wouldn't imagine having to change once per month my Windows password, my SVN password, the password on the corporate website, and five or six other passwords which would appear if we were using different data sources for each of those systems.This being said, I can see some drawbacks of this approach:If you don't benefit, like in my case, from having several disparate systems linked to a single Active Directory, I don't see why would one chose AD instead of an SQL database.One mistake in configuration, and any registered user can also access any of your machines. This is risky.I would imagine Active Directory being slower than an average SQL database. This being said, I haven't done any profiling and benchmarking to have any evidence of this assertion.Active Directory is a tree, with a purpose of organizing and grouping entities and assigning permissions to them. For an ordinary website which requires authentication, such structure is an overkill. A simple flat table is largely enough.Using Active Directory is not an usual thing for a website. When you start developing it, you encounter lots of issues which are not obvious to solve, including the famous error telling that Active Directory is unwilling to process your request, because... well, it's in a bad mood today. Unit-testing the solution is not straightforward too, and there are things which can be easily missed, like the characters you should escape (given that there are two distinct lists) to avoid AD Injection.I imagine there might be some drawbacks when it comes to configuration and deployment, even if personally, I haven't encountered any.