A great post from Michael Mullary over Engine Yard blog on the pros and cons of LDAP and what can be learned from its insuccess.
I especially liked what Michael identified as some of the possible causes of LDAP’s ”failure”
- Telecom protocols FTL
- Access control that exceeded human brain capacity
- Interesting data wanted to be relational
If you take a step back and look at the first two points you’ll realize they are referring to one very important aspect of every system: complexity. That sort of complexity in the sense Emil Eifrem and myself talked about and comsidered to be a new dimension of NoSQL scalability.
The last point is as important. Everything we know is connected in one way or another to other things around. Sometimes the relationships are predefined, but there are many cases when we are adding ad-hoc connections.
But what’s the connection with NoSQL? Except graph databases, most of the other NoSQL solutions tend to have a hard time modeling relationships (that should be obvious as NoSQL has stepped out of the Codd’s model). And while this might not usually be a problem at the storage level it can definitely represent an issue at querying level. Take for example key-value stores and ask yourself how will you deal with range queries. Or take a look at how document stores are modelling relationships and their implications.
Modelling interconnected data in a non relational way is a challenge and we will have to figure out if we can design applications in which we ignore some real-life dimensions or we need to come up with ways to handle pre-existant or ad-hoc relationships.
LDAP = Forgotten NoSQL
-
infynyxx reblogged this from nosql and added:
LDAP = Forgotten NoSQL
-
nosql posted this
