1

This excellent answer explains the advantages of LDAP/Directories over RDBMSes under the right circumstances, but only mentions user account and auth-centric information as being the types of data to store in a directory.

The answer basically attributes the following advantages to a directory:

  • Tuned for ultra-fast reads, typical in an auth system
  • Scalability
  • Replication capabilities out of the box that are not easily achieved with most RDBMSes
  • Interoperability

I'm wondering what other use cases might warrant storing data in a directory. If read performance is the main benefit, then I would think any OLAP storage might be a decent candidate, such as a data warehouse or report generating system.

But I've had such limited experience with LDAP and directories, it's tough for me to see the "forest through the trees"; I've only seen user data stored in a directory, such as:

DC=example, DC=org, OU=Customer Service, CN=John Smith

I'm not entirely sure how this would translate to storing/querying non-user data.

Can someone clue me in as to what use cases, besides user/auth systems, would be prime candidates for storage in a directory, and provide an example or two of what an entry would look like in the directory, just so I can wrap my brain around how to store/organize non-user data?

Community
  • 1
  • 1
smeeb
  • 27,777
  • 57
  • 250
  • 447

1 Answers1

2

Mine contains:

  • users
  • roles
  • password policies
  • entries for email accounts used by the system
  • entries for server hosts
  • entries for VM guests, arranged under their respective hosts
  • entries for server software modules, e.g. Apache HTTPD, Tomcat, MySQL, OpenLDAP itself, SSH, etc, and their replication slaves where applicable, showing their public URLs, arranged under their respective hosts or guests.
  • The previous item also includes our mail server, which is operated externally by the ISP, with URLs for its SMTP and POP3 ports and for the Webmail interface, the sort of thing it is too easy to forget.
  • entries for networks and subnets
  • entries for countries we operate in and the divisions that are in those countries

In other words, beside user/auth information, a whole lot of stuff that is:

  • naturally hierarchical
  • non-transactional
  • mostly indicative
  • probably wouldn't be stored in a database at all, and
  • that can benefit from being organized and visible in one place, subject to backup and replication, etc.

I also have an entry for the Site itself, containing its title &c for display on web pages.

I also have a subtree for Products, showing their inter-relationships and bills of materials: our system doesn't really have a catalog per se but it does need to be explorable hierarchically via a Web page. These products are really documentSeries, each owning one or more documents, again with URLs. This actually serves to organize the site, without planting links everywhere.

I also use it as an inventory of certain lab equipment that again wouldn't appear in a database.

And I haven't had to write a single table schema.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks @EJP (+1) - this is starting to make sense, but I still have a few questions. (1) Can you explain to me why data that is *hierarchial* in nature is better suited for a directory service than an RDBMS; I'm totally missing that argument. Also I'm having a tough time understanding how many of your example are hierachial in natur. And (2) Just cherry picking your last example (inventory of certain lab equipment), you imply that one would never store that kind of info in a DB - **why not?** I think if you can explain these to me I should be all set. Thanks again! – smeeb May 04 '15 at 01:52
  • 2
    LDAP entries have children. RDMS rows don't, at least not inherently, although of course you can arrange a schema for that if you need it. Also LDAP explorers *show* you the hierarchy. A server can contain VM guests and services, and the VM guests can also contain services, and the services can have URLs. – user207421 May 04 '15 at 03:27
  • 1
    As for the lab equipment, it gets bought and sold all right but it really isn't part of the business to do so. Normally it would only appear in the accounting system as an inventory or plant asset, possibly via its cost only. Putting it in LDAP shows me where it is both physically and logically (plugins within mainframes for example), gives me somewhere to put its serial number, etc. – user207421 May 04 '15 at 07:38
  • 1
    Thanks again - I can't award the bounty for another 9 hours, but you got it :-) – smeeb May 04 '15 at 07:54
  • @smeeb It also depends on size and needed performance. The bigger your data is, the faster your database will be in relation to your directory service when querying it. Another comparison would be file system (hierarchical) vs. RDBMS (relational), as a naive implementation of a directory service could be modeled inside a file system (directories = DC/OU, files = CN). – user121391 Oct 14 '16 at 13:26