Is the relational model of data storage the best, most effiicient 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 impersontating 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.
I got to thinking the other day: exactly when do you have a "content management system?" We've all built apps that manage content, but when do you graduate from a "relational database with an admin section" (RDBWAAS) to the lofty and deserved title of "content management system?" (Incidentally, I struggled…
The legendary Fabian Pascal showed up yesterday to tell us all that we were stupid over in the relational data model post. Specifically, his comment was: None of you know the relational model, which is why you think current products are relational, which they are not. …
PostgreSQL 8: Inheritance: Joseph Scott -- a champion of PostgreSQL -- pointed this little feature out in a comment to my post on the relational data model. It's a method in PostgreSQL of subclassing tables. You can create a table that would have a one-to-one relationship with a "parent" table…
One of the continuing quandries I've had with XML is the management of multiple XML documents. If I have one, big XML document, then it's easy to work with — to parse with an API, to transform with XSLT, to query with XPath. But what if I have many documents?…
I've had discussions with folks along the same lines and I usually come back to the relational model. One reason for this may be the years of development it has ahead of other, more "modern" models.
A blending of OO and Relational would be something like PostgreSQL's table inheritance (they call it Object Relational). Here's another example of how this works. Unfortunately there are some drawbacks to using this, so I've avoided using it in production systems thus far.
If you are interested, the site http://www.dbdebunk.com/ has a lot of material on this discussion, and Fabian Pascal's papers and books expand greatly on the matter.
The real problem is that you are so used to work the relational way that you are thinking through this model. For example you are saying that the object model is inferior in terms of data insertion and update because you are thinking you need to adapt it to a table: if you are using a true object database it's not you're problem it's the problem of the database engine. (And there is different Object Query Language existing.)
You have exactly the same problem with an xml based model, you are wondering about querying your data, or even if there is a proper data index existing.
We are all using relational data storage (or adapting our new way of thinking to the relational model) because of the market share behind it. Relational is really good at what it's doing this day because everybody as adapted to it, there is thousands of people who have done research around this model, who have tuned the way we are accessing it. There is thousands of tools existing using it.
Try to search for a true object database engine ... you will find a few but nothing like Oracle, DB2 or MySQL. The same is true for XML database engines. The fee for entering the market is way to high for other models to play today a significant role.
Guillaume
In terms of XML database structures, SQL Server 2005 seems to have incorporated greater XML support, including a native XML data type... which of course allows for a hybrid relational/XML structure...
As to how well it will go? So far I've heard the performance ain't great, but it's still in beta...
The real problem is that you are so used to work the relational way that you are thinking through this model.
That's absolutely true. For most developers, the relational model taints our evaluation of anything else.
But as the rest of your post indicates, the relational model is most well support by current tools. Where people run into problems, I think, is when they try to implement the other models using a relational database and get frustrated when it doesn't work as well.
I think it's safe to say that the relational model is the best model when using a relational database.
I ran across the Associative Model of Data a few years ago. This is certainly an interesting concept, but the relational model is second nature and sometime I just talk in SQL.
I think it’s safe to say that the relational model is the best model when using a relational database.
Probably :)
Relational models are the lingua franca of development these days. Everybody understands them, everybody is familiar with tools to work with them, and everybody trusts that they work.
So from a social standpoint the relational model is best, from a technical standpoint? I don't know. I don't know enough about other technologies to make that call, but I do know that the first thing I usually do when I'm starting a project is build an object interface to my relational database. So I'm open to the idea that there's a better way. For now though relational models are so pervasive (and useful) that it's hard to argue against them.
None of you know the relational model, which is why you think current products are relational, which they are not.
This whole thread is nonsense, because you never defined what "best" means, and "best for what?".
FP
fabian & deane,
Very entertaining discussion you've both been having... Just wanted to point out that fabian did not actually attempt to educate or answer the primary question asked. Which is in essence: "Given the current mechanisms of storing and retrieving data, be that files structured as XML, CSV, etc.. through to a 'correctly' implemented relational model... what are the pro's and con's people who have been using them in the real world found?"
Now since fabian is such a pro-ponent for a 'correctly' implemented relational model, how about he give us some examples of how it has solved problems that the others haven't? Can it solve all possible problems? are there any possible situations it isn't the 'best' solution.... and feel free to point out that "the relational model solves issue x... however most implementations fail to solve it because of y..."
Note: Having read the discussion you two had, I've got to say that Fabian added absolutely nothing constructive to the correct discussion, he just sounds like someone who wants to appear intelligent by pointing out that everyone is dumb... If you're so intelligent enlighten us by actually answering the question as it's meant, and keep your stupid quibbles of choice of language to yourself, I'm sure you're intelligent enough to interpret the meaning of the question (or are you?)
B
Biscuit,
Let me get this straight: I, with three books, dozens of seminars over the years, hundreds of articles and a web site, most of which are free, don't contribute enything; but people who have no clue what they're talking about, they do????
If you believe that you can get a serious eduaction in the fundamentals of a field in threads like these, u're belaboring under a delusion. Education requires serious effort and time with serious sources. Only then can you judge who contributes and who doesn't.
My suspicion is that you have neither the time, nor the inclination for serious learning, which is why you expect people here to spoonfeed you. Then you get what you deserve.
I don't really appreciate Fabian's tone, but that is my personal opinion and irrelavent to the debate. I have been drawn to read a little bit of what he has written and I will continue to do so.
Don't kid yourself Noel, he's a self-centered prick who has done nothing but hurl insults at people for asking questions. Deane initially asked for people's thoughts, and was thrown a one-two haymaker by this clown just because he wasn't an "expert" in the field and made the mistake of using words other than those approved of by Fabian.
A true intellectual who actually cared about their field would take the time to point out a mistake or two in someone's thinking and maybe point them in the right direction, not brow beat them because they think they don't know any better. If you're not trying to teach others and help educate us on our shortcomings, why did you write three books, give dozens of seminars, and blah blah blah? Just to say you could? To hear the sound of your own voice? Yeah, I thought so.
In the end, its humorous that in the span of two or three posts the guy can say "I'll answer questions IF I have time", and then spend the past week or two arguing with a bunch of uneducated idiots who have nothing to say and nothing to contribute.
Gimme a break, Fabian...
Here are a couple points I've come to believe --
Fabian is not mad at us, he's mad at Larry Ellison. According to what I'm reading, there is no "true relational database system." The deficiencies are at the product level, not the implementation level. We're just doing the best we can with the (apparently horribly flawed) tools we've been given.
Fabian has lost sight of the forest for the trees. The fact is, where and how you persist data is often a very small part of an app. But this is Fabian's entire life, and he's fixated on that part of it to the exclusion of all else. He believes that the success or failure of an app is utterly and completely dependent on the internal structure of its data store, which is patently ridiculous, but that doesn't seem to matter.
Fabian will win any argument about database theory. He's obviously brilliant in that regard. But, again, database theory is a small part of the entire application stack. Consequently, Fabian will lose arguments about application design and implementation because he doesn't care about anything beyond data storage. Everything else is apparently so much fluff.
I find myself thinking about how I can persist data given the tools I have and not piss Fabian off. I don't know how I can do it. I could walk again from SQL databases altogether, store stuff in text files, and try to avoid the whole argument, but given his prior comments about XML, he'd likely hate that too.
So does that dead horse twitch when you guys kick it or what?
Deane,
You said:
Out of curiosity I must ask: what kind of applications is it you build where the data is so much less important than the code? And what happens to the data if you store it all in text files of your own devising, when your app becomes outdated and someone wants to write a replacement?
Explanations --
The fact is, where and how you persist data is often a very small part of an app
The actual data is important, but where and how I persist it is pretty much a solved problem. Like I said in another rebuttal to Fabian, SQL databases have let me persist and retrieve data the way I have needed to for years. There are precious few data storage problems I've found that a SQL database couldn't solve quite handily.
In retrospect, this comment was a little off. What I was trying to get at is this: if you have a system that let's you persist and retrieve data in the manner that you need, then data storage is a small part of the app.
I'm rethinking this statement now. It was poorly worded.
But, again, database theory is a small part of the entire application stack
I stand by this. I know how to design a build a SQL database that will let me persist and retrieve data in the manner I need to. Do I theorize about internal database design and organization beyond this? No, not much. Consequently, that's a very small part of what I do in an app.
I could walk again from SQL databases altogether, store stuff in text files
This was meant to be humorous by pointing out the lengths someone would have to go to avoid an argument with Fabian.
this thread is hilarious, and worth bookmarking for several reasons
unfortunately, i can contribute little to the actual discussion, and really want to avoid saying anything that will put me on buddy's shit list
again
may i suggest that logical data modelling with constraints and relationships is a development task should never be skipped
but what do i know—i like nulls, eh
;o)
To Deane's original question, "And do we understand them simply because they’re generally the best way to do things? I’m curious.", all I can venture to say is that currently only the relational model is based on a solid theoretical foundation.
None of the other methods have any mathematical or scientific foundation.
Object Databases? Ask a few experts what Object Orientation is, and they'll come up with different answers, sometimes even contradictory. For example, many consider that encapsulation (a core OO principle) is violated by inheritance, another core OO principle.
My experience has been that when we develop without violating fundamental principles, we end up with a good application and good data. If we go for the latest fad, we do not end up with a good application, if we manage to finish the task.
I would prefer to stick to relational database technology, until somebody comes up with something demonstrably superior.
Deane
As FP says , "Education requires serious effort and time with serious sources. Only then can you judge who contributes and who doesn’t."
If you can make 1 hour a day you should start to get a foothold in about 3-6 months so long as YOU READ THE RIGHT MATERIAL .
To stop you wasting time on the wrong material as I initially did , these are the first 2 books to read . Expect to cover between 3 and 7 pages per hour :-
If you read the above 2 books you will know more about data management than 90+% of the practitioners who will also have come through programming but without any formal education in data and databases , only training .
For treatment of missing/innapplicable information and logic systems I specifically recommend David Mc Goveran's series "Nothing from Nothing" in "Relational Database Writings 1994-1997" .
Good Luck
Simon
I've just discovered we've been granted the honor of a link from Fabian's "To Laugh or Cry" links page. Thus, the sudden interest.
