Using a Directory Service instead of a Database

Question

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?

Answer 1

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:

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

2. One mistake in configuration, and any registered user can also access any of your machines. This is risky.

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

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

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

6. I imagine there might be some drawbacks when it comes to configuration and deployment, even if personally, I haven't encountered any.

Answer 2

LDAP servers are often used in a web environment and often back user data. Single Sign On is nearly always backed by an LDAP data store. That one should always use a (relational) database rather than other data stores is... poor.

The key with any data store is to use the one that is most appropriate for the data. Sometimes the data fits better in a traditional database, sometimes it is best in a nosql style data store, other times its a directory. One should use the appropriate data store for the data.

The thing that LDAP excels at is fast lookups for rarely changing data. Going back to the user data (as an example), the email, password, name, and roles rarely change.

Similarly, cached data often fits well into a directory where you compute the data and then load it (which is then frequently read).

Directories, however, don't like frequently updating data. Its a trade off - you can optimize for reads if you penalize writes. Rebuilding indexes on the fly is not something that LDAP does well when comparing it to a relational database.

How (and how well) transactions work are still within flux within LDAP. If you want to have multiple updates be a single atomic operation, this may cause problems.

Referential integrity (foreign keys, unique constraints) does not exist within LDAP. Similarly, if this is what you need, you may find it difficult.

While one could pack JSON data into a field within LDAP, LDAP itself doesn't try to do the data structures that are present in other databases.

If you are doing a not-occasional number of writes or updates (and thus impacting performance), 'joins' of data rather than filters, or want faster consistency than ldap replication offers you may find that LDAP data store is not appropriate.

But as a data store for stuff that rarely changes, it is often one of the best.

Answer 3

A directory is a database, although one you don't use SQL to access. So, just call it a NoSQL database and you're cool again!

The only constraint would be that on a directory the data structures (the schema) are fixed, so they might not be adequate for most cases. But if you can express your problem space in that structure, then it could be just as good.