Schema-less db FTW! 40 yrs ago, EF Codd tied semantics to performance in a shotgun wedding. Now a divorce?
A while back, a colleague used the phrase model-free. I didn't really know what he meant, but I'm starting to think I like it. He was describing a system which provides services over a set of resources (in the RESTful sense) that required no assumptions about any file format or data model for the resources. The services were along the lines of storage, retrieval, search, and access control. So, none of these directly depend on the structure of the resources. (Well, search has to get keywords somehow.) Of course, these features are quite useful and end up getting rewritten over and over again for every new application. Wouldn't it be smart to factor out features like this that can be provided independently of the specifics of a given application? The result might be a sort of schema-less data store in which the data format of the resources would be determined by convention between the producers and the consumers of any particular type of resource - more or less how MIME types work on the web.
Data management is getting to be a colossal problem and use-cases poorly served by the relational database are popping up in increasing numbers. A lot of folks are wondering if it's time to junk the RDBMS?. Relational DBs have tremendous advantages, but also some well-known ways to bite your butt. They're inflexible in that schemas are hard to change. They can inhibit interoperability. Traditional data integration between separately developed schemas is labor intensive and unscalable. Then there's the whole writhing can of worms labeled object-relational mapping.
I'm not sure I can put my finger right on it, but there's a similarity in spirit between REST and schema-less data management.
See also:
I was so disappointed when I found out that FTW didn't stand for what I thought it did.
ReplyDelete