Is the relational model of data storage the best, most efficient way to store data? I’m talking about the traditional database model of tables, fields, row, foreign keys, etc.
What are the other ways? There’s object oriented, where you have a table of classes and attributes, object instances and properties (the “key-value” table). Then there’s XML and the document-centric model. I’m sure there are others, but I’ve worked with these two so they jump out at me.
Sometimes I think that these methods are just ways to impersonate the relational model without the problems of a rigid data structure. Because, in my experience, the relational model is, without a doubt, the easiest to store data in and query, primarily because SQL has been designed around it.
In contrast, the object-oriented method is inferior in terms of inserting and updating data (you have one table row for every object property, so you have to do multiple updates and inserts) and in terms of querying data (you have to use temporary tables like crazy to iterate through different filters to get your results).
It’s easy to store things in XML, but searching has problems, primarily that there aren’t good and simple systems around for managing the data in aggregate. Yes, XPath will let you get information from a single XML document, but what if you have 10,000 XML documents in a directory? Find me all with a “author” tag equal to “Hemingway” – this is trivial with a relational database, but with XML, not so much. (Are there good systems for this yet? I’ve been complaining about this for a long time.)
So why do we ever entertain storage methods other than relational? One of the big reasons, I think, is that other methods make it easy to maintain data models. The object-oriented method, for instance, lets you create new “classes” by inserting table rows, rather than by changing the actual table structure. And XML is even more flexible. For all its advantages, relational databases have rigid structures.
So, again I ask: is the relational model the best way of storing data? If maintaining the data model (designing and changing the defined tables and columns) was abstracted away to be utterly trivial, would you consider anything else? Have you had a decision recently where you specifically chose another method over the relational method? Why? What was the application that made you think another way of doing things was better?
This question has come up in my mind because I keep running into systems that don’t do things relationally, and instead have many different ways for impersonating the relational model. For example –
I was on a conference call the other day with a vendor who sells an enterprise-level CMS that relies heavily on XML. I was trying to get him to explain to me how I could create a “book” object (for example), and just link to an “author” object instead of embedding the author data in the book object. I found myself saying, “…you know, like if I just had a foreign key in a relational database.”
Relational data models are great reference implementations because all developers understand them. And do we understand them simply because they’re generally the best way to do things? I’m curious.