Choosing between a directory server (a.k.a LDAP database) and an RDBMS

Question

In my project, where I'm the lead developer, we earlier had a network configuration that was stored a single XML file. The configuration contains info about a network layout - its constituent hosts, various details about each host like OS, platform, users configured in each them, several attributes for each user and so on. In the forthcoming version of the product, we want to move the data into a database of some sort since the configuration will be expanded to include more elements and details and maintaining them in XML files will start becoming cumbersome.

The first choice was an RDBMS. However owing to the hierarchical nature of the configuration data and with the expandability criterion, a directory server seemed a better choice. The motivations for going with a directory server are

1. It is easier to model hierarchical data in a directory server than in an RDBMS.

2. It is also much easier to create/define new entity types that extend a base type with additional attributes. This is very attractive from a problem-solving point-of-view.

3. The configuration data will be read more often than updated. Though performance is not a concern, a directory server suits this characteristic very well.

After about a week of bootstrapping myself on the basics of LDAP and directory servers, I'm now somewhat skeptical about the choice of a directory server. I see a few issues:

1. LDAP is less mainstream than an RDBMS. Lot more people have had experience with some SQL and can get started off faster with an RDBMS than a directory server. As I mentioned earlier, it took me a little more than a week to learn just the basics of LDAP (how to create a schema, define a DIT, add entries, export data to LDIF files and so on). This is important because when a new member joins the team, he/she is not faced with a learning curve.

2. In the future we might have more data to be maintained and stored in the database. A directory server may not be a good choice for such data (e.g. data than may be updated as often as it is read). Having two storage mechanisms is a burden, in my opinion.

3. On a more political front, I won't be blamed/fired for choosing an RDBMS even if it is not well-suited for the problem currently in hand. With a directory server, if point 2 above becomes a reality, I don't want to be answering the question "Why didn't you think of that earlier?".

I'm looking for advice on how to make the choice. Has anyone faced a similar situation before?

EDIT-1: We had a discussion on this within the project where I put forth the exact points I made here. It is very likely that we'll choose an RDBMS without any further evaluation due to the following reasons:

1. Point 2 was deemed more important than anything else.

2. The thinking within my unit seems to be rather conservative with people at all levels wanting to play it safe. I really can't blame them for it though.

3. "Why not an RDBMS?" was the first question. "Can it done with an RDBMS?" was the second. I finally got the message.

Answer 1

Normally I would run away from LDAP as fast as possible however you just invoked the two magic phrases that make LDAP the better choice " the hierarchical nature of the configuration data " and " configuration data ".

LDAP was designed for this (and only for this) type of data.

There are other more pragmatic reasons for choosing LDAP.

1. All LDAPs are the same. Its an access protocol not a database implementation so whether your customer uses an opensource LDAP or a commercial one your software will not need to change.

2. All RDBMSs are different. Whatever RDBMS you choose there will be at least one customer who has standardised on a different incompatable RDBMS -- if you product is reasonably succesful you will end up maintaining a fork for at least MySQL, Postgress, SQLServer, Oracle, DB2 and Sybase.

If your customer/boss grumbles that its not as buletproof/performant/transactional as ORACLE/DB2 point out that the customer has the option of using ORACLE's or DB2's LDAP implementation.

The only real downside is the lack of LDAP experience out there. Most developers only experience of LDAPs is with the default user security schema which comes with J2EE.

LDAP schemas are databases and will require database like adminstration and change control procedures!

2. List item

Answer 2

If you're just looking for a change configuration DB, RDBMS is the way to go. This is a common IT problem and there are various commercial solutions. It might be worth taking a look to see what's out there before investing heavily in a custom solution.

If you're looking to eventually incorporate integrated authentication across multiple platforms (windows / linux / etc.), then LDAP is the way to go. Not only do most server and desktop OS's support LDAP authentication natively, but LDAP can easily be clustered or synchronized across multiple sites.

It's quite possible that you will end up with a hybrid solution. A majority of your change control db (CCDB) can reside in RDBMS, but authentication can be serviced with an LDAP cluster. A unified front-end can manage information in both. Avoid keeping account passwords in your CCDB, for security reasons use LDAP instead.

Whether you go with RDBMS or LDAP, you'll likely to write wrapper scripts, applications, or web-based front-ends to add / update information in your CCDB. This helps reduce the learning curve for new employees and both simplifies and controls updates to the change control database.

Don't underestimate the risks of pointing a new employee at the raw RDBMS and hoping for the best. Schemas for comprehensive CCDBs can be very complex, regardless of which technology you choose to model them.