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
It is easier to model hierarchical data in a directory server than in an RDBMS.
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.
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:
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.
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.
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:
Point 2 was deemed more important than anything else.
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.
"Why not an RDBMS?" was the first question. "Can it done with an RDBMS?" was the second. I finally got the message.
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.
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.
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!
- List item
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.
I'd go with a RDBMS approach for the following reasons:
- You can modify and expand it's structure easily.
- If your network you're modelling is anything like mine, it would be a disaster to try and model it in a hierarchical manner. (It's not essentially.). e.g. firewall rules, server's accessing other servers, subnet's etc.
- It's extremelly easy to report on.
- It's easier to find developers skilled in SQL then in LDAP.
- It's relatively easy to cater for special cases, can this be done easily in LDAP?
Having said that, I'm more familiar with RDBMS approach, so i'm biased.
The answer is simple: if you need a directory, use LDAP. If you need a database, use a RDBMS. Since your goal is to have a directory-like structure (it sounds much like a "phonebook"), go with LDAP. A RDBMS would be too much overhead for what you need.
I'm not sure the "noone got fired for..." argument applies here. After all, you really need a directory server, we are not talking about a request that stands in the middle of an imaginable LDAP-Database axis.
I would definitely go with LDAP, although I cannot put myself in the shoes of a man that might get fired for choosing a directory server solution to match a directory server problem...
I'd be inclined to lean towards LDAP due to the structure of your data, and although, I'm of the opinion that there need to be more people out there who deal with hierarchical databases and get away from the "RDBMS is the only database" mentality, I don't know of an easily portable LDAP server that you could embed into a larger application.
You could use SQLite if you wanted to go the DRBMS route, but I'd actually go for a third option -- XML databases. As you're already using XML, it should hopefully be an easy switch to move to something like Berkeley DB XML for the storage. You can also check Wikipedia for a list of other alternatives
(and a disclaimer -- I've never used any XML databases; I have used OpenLDAP, iDS, and eDirectory on the LDAP side and Oracle, SQL Server, mySQL, PostgreSQL, SQLite and others on the RDBMS side)
来源：https://stackoverflow.com/questions/1491184/choosing-between-a-directory-server-a-k-a-ldap-database-and-an-rdbms