RDBMS vs. LDAP

Last issue I talked about Thor Technologies, its new round of funding and its “best of breed” solutions. But what the Thor folks really wanted to talk about was the use of SQL-based relational databases for storage of identity and provisioning information.

Of course, once I got into conversation with Thor Product Architect Nishant Kaushik, Vice President of Business Development John Aisien, and Product Manager Ranjeet Vidwans we soon discovered that until we defined our terms, we were simply going to speak at cross purposes.

We all agreed that corporate and/or enterprise-wide identity data belonged in a directory. That might be a single directory service (such as Sun’s or Novell’s), or a meta-directory (as offered by many different entities). Provided the data physically resided someplace, it could even be a virtual directory – a series of pointers to the actual data.

What the Thorians were interested in was where the provisioning data, the rules and roles for example, was stored. They felt – as did their customers, they claimed – that the robust nature of a standard relational database management system (RDBMS) was required. Well, of course that’s what Thor’s customers feel. Either they came to Thor because they required an RDBMS or, having come to Thor, they were convinced by the slick-talking marketing guys that an RDBMS was de rigueur.

An RDBMS does offer some advantages over a typical LDAP-enabled directory datastore (LDDS). But it also has a few disadvantages. While the RDBMS is relatively quicker for write operations, it’s generally slower for reads. The RDBMS will typically offer multiple indices with a lower overhead than the LDDS (if the LDDS even offers a way to construct a second index or more). Most LDDS though, are able to be partitioned and replicated thus making them pervasive and ubiquitous – they are always available and available from anywhere. While a replicated (and even partitioned) RDBMS is possible, it’s far from the typical installation, while with the LDDS these things are highly recommended, if not a requirement.

Accuracy and timeliness are provided in different ways by the two systems. Generally, the LDDS is a “loosely-coupled” system – updates and replications are not instantaneous to all instances. With an RDBMS, most changes are done with a transaction – either the entire transaction succeeds, or the entire transaction fails. The LDDS could also be layered with a transaction tracking system, but it typically is not. Replications are done on a set schedule and are done on a one-to-one basis so that different instances of the datastore may not contain 100% of the same information at any given point in time.

Auditing is often handled through the transaction logs with the RDBMS but is usually an interrupt-driven “event notification” system for the LDDS. In either case, though, it’s usually something outside of the system that monitors the auditing.

Neither system is “right,” neither is “wrong.” As the carnival huckster puts it, you pays your money and you takes your choice. You decide which benefits are necessary for your project and then choose the system that provides the greatest number of those benefits. Some will like Thor’s Xcellerate package because of the RDBMS requirement and some won’t. But rather than get bogged down in data storage details, save your energy for the bigger fight – the office politics. We’ll revisit that subject in the next issue.