Using an LDAP server as a database, how practical is it?

Question

I want to learn how practical it is to use an LDAP server (like AD) as a database. Be more clear; How much does it make sense to use an LDAP server instead of using an RDBMS to store data?

I can guess that most of you might just say “this is not so,” but there may be some reason to make it meaningful (especially business);

First, a few points;

• Each table becomes a container, and each row becomes a new entity as a child. String objects contain attributes for columns. Thus, you present your data in this way. (This should be the most meaningful presentation, I think suggestions are welcome).
• Thus, storing data such as a database server is possible, but the lack of support for FK and PK (not sure about PK) is a problem. On the other hand, it supports attribute indexing (refers to a column) (not sure how efficient it is). Thus, data consistency is the responsibility of the application layer.

Why would anyone do this?

• The data that the application uses / stores exactly matches the existing data in AD. (Users, machines, department information, etc.) (But for the existing entity schema, some configuration is required, and for not-so-related data, new schema definitions are needed.)
• (I think the strongest reason would be this: business related). Most medium-sized companies have very well-tuned AD servers (replicated, backups, etc.), but they do not have such a database setting (you can comment on it as much as you want). Tell me, when you sell your software that requires installing a database for these companies, they must manage the database settings; but if you say you don’t need to configure and manage the database, you can just use the existing AD , it sounds attractive.

Obviously, there are many drawbacks to refusing to use the database; feel free to mention them, but assume that they are acceptable. (I can say more if the question is not clear enough.)

Answer 1

LDAP is a terrible tool for supporting most business data .

Think of a typical one-to-many relationship — say, customers and orders. One customer has many orders.

Unable to present this data in the LDAP directory.

You can try to use a “foreign key” by making each record of this class of objects the attribute “foreign key”, but your referential integrity just left the window. Cascades cannot be deleted.

You can try to have a customer object that has children ordering it. However, you just introduced a specific hierarchy — you are now attached to it.

And this is the easiest use case. When you begin to enter into more complex relationships, you basically reinvent the RDBMS in a different system designed for a different purpose. The key in the name is the catalog .

If you keep a phone book, then be sure to use LDAP. Use a real database for anything else.

Answer 2

For relatively small flexible datasets, I find the LDAP solution workable. However, the DBMS provides a number of significant advantages:

• Backup and restore : any database will provide ACID properties. And RDBMS backups are usually easy to script and provide several options (for example, full or differential). I just don’t know with LDAP, but I think that these qualities are not so widespread.
• Reporting : AFAIK LDAP does not allow you to easily add JOIN values, especially since such things as calculating summation. That way, you would put a lot of effort into the application code to reproduce these behaviors when you need reports. And which application does not end up?
• Indexing : It looks like there is indexing in LDAP solutions, but again it seems to hit or miss. While, it would seem, all the databases have made some real efforts to get this right.

I think that any serious business system repository should be copied in the same way that you think LDAP is in most environments. If what you really need is flexibility in terms of representing the hierarchy and the ability to define dynamic schemas, I would suggest looking for NoSQL solutions or the Java Content repository.

Answer 3

LDAP is very useful for storing this information, and if you want it, you can use it. RDMS is simply more convenient in ORM systems. Your logic of duration with LDAP will be so complicated. And it is worth mentioning that this is not a standard approach - people who will support the project will spend more time analyzing.

I used this approach for fun, I am creating a phone book from Active Directory, but I do not think it is a good idea to use LDAP as a store for business applications.

Answer 4

In short: use the right tool for the right job.

When people see LDAP, you have already set the wait on your system. Do not forget that L is light weight. LDAP was designed to access directories over a network .

Using the "directory database" you can create a specific type of application. If you can map your data to a tree similar to a data structure, it will work. Of course, I would not want to shoot video with LDAP! You might probably hack something, but I would prefer a sail server.

If you use a tool that is not intended for what it should do, there may be hidden errors. Thus, the disadvantage is that you have to test the material, which would be given in some cases.

This is not only a technical concern . Your operational support team may frown on your application, as they will have certain expectations / prejudices based on the architectural features of your applications. Imagine their surprise if you provide them with a CRM system (website + files and pop-up email, etc.) on the LDAP server as a database for support.

Answer 5

If I were in your place, I would go to one of the NoSQL db solutions, rather than try to use LDAP. LDAP is great for things like storing user and employee information, but it's scary to interact when you need to make changes. NoSQL db allows you to store your data as you want, without the overhead of an RDBMS that you would like to avoid.

Answer 6

The answer is really simple. Think of CRUD ( C reate, R ead, U pdate, D elete). If a lot of Read is done on your system, you might consider using LDAP. Because LDAP is fast and clear. If other operations are done more, RDMS will be the best option.