Home/ Questions/Q 382521
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T15:11:27+00:00

In my project, where I’m the lead developer, we earlier had a network configuration

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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!

    1. List item
    • 0