Is the Relational Model the Best Model?

By Deane Barker on September 1, 2005

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.

Gadgetopia
What This Links To
What Links Here

Comments

  1. 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.

  2. 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

  3. 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…

  4. 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.

  5. 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.

  6. 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

  7. 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

  8. 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.

  9. 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.

  10. 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…

  11. 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.

  12. Deane,

    You said:

    • “The fact is, where and how you persist data is often a very small part of an app”
    • “But, again, database theory is a small part of the entire application stack”
    • “I could walk again from SQL databases altogether, store stuff in text files”

    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?

  13. 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.

  14. 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)

  15. 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.

  16. 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 :-

    • “Practical issues in Database Management” Fabian Pascal
    • “An Introduction to Database Systems” Chris Date .

    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

  17. 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.

  18. Fabian,

    Apologies for not responding sooner (I’ve been away)… But in answer to your full on response ‘Let me get this straight: … I don’t contribute enything;’

    First off I did NOT say you don’t contribute anything… I said ‘fabian did not actually attempt to educate or answer the primary question asked’. ie: you have not actually contributed (beyond insulting a lot of people) anything to the discussion at hand.

    I have no doubt at all that you are extremely knowledgeable about the relational model and how it should and has been used. Fantastic! Good for you! You are in the perfect position to enter a debate on how it actually satisfies any and every data requirement out there.

    But that is not what you’ve done, you’ve just told us we’re all idiots & couldn’t learn anything even if it was spoonfed to you, etc… Myself I tried to point out to you (using your own methods of communication) how you’ve failed us, and instead you try to tell me that I ‘expect people here to spoonfeed …’ me.

    Guess what I (like many of the Gadgetopia audience) like reading about technology, and educating myself on various techniques out in the world, I know a reasonable amount about SQL and data structures, but I also know that there are many people out there more advanced than myself in this area (there are also many who are not up to my skill level).

    As such I looked forward to hearing a debate amongst the experts of various forms of data storage about what are some pro’s and con’s.. Perhaps even a few links to where I could find out more about various techniques, perhaps hearing about something I haven’t come across in my own research. Instead you come in swinging and the debate (while being immensely entertaining) has also been a great dissapointment.

    And I believe the blame of this debate not living up to its potential, can be laid squarely at your feet. Now if you want to actually contribute the debate, here’s some tips for you.

    • Don’t call your audience members or fellow participants idiots
    • Accept that as you know some things they don’t, they also know some things you don’t (perhaps an exchange of knowledge could be useful)

    We await your response, I hope it will actually be appropriate this time.

    B

  19. you’ve just told us we’re all idiots & couldn’t learn anything even if it was spoonfed to you, etc…

    After following this discussion from the outset, I couldn’t agree more. Doesn’t that describe a troll pretty well? Every time I read something posted by Our Friend Fabian I think the same thing. He may have credentials, but a troll is a troll.

  20. Hey Biscuit and everyone else, Fabian didn’t say that all of us are idiots, he simply said “None of you know the relational model…”. Not knowing the relational model doesn’t automatically mean being an idiot.

    The current DBMS products today such as SQL Server, Oracle, and MySQL are simply SQL DBMS’s, not relational “databases” (DBMS’s) in the proper sense of the term “relational”. These products attempt to implement the relational data model; unfortunately they do it very poorly. SQL itself is a very poor implementation of relational algebra (calculus?). Because these products do not adhere fully to the relational data model, they suffer from various problems ranging from physical ones such as slow DBMS performance, scalability problems, and lack of integrity constraints risking data to corruption, to logical ones such as the complexity of designing databases correctly, query formulation, redundancy problems, representation problems (such as representing hierarchies like organization charts in the database), and representing missing data and historical (temporal) data, etc.

    The relational model is the scientific foundation of data management; the model itself is founded on predicate logic and set theory. That’s why it seems so theoretical when you read books and other documents about it. But designing databases without the knowledge of the relational model is like designing a building without the knowledge of physics, or performing a surgical operation without the knowledge of human anatomy.

    If we keep on equating SQL products with “relational products”, and if we keep on thinking about databases and DBMS’s simply as “storage mechanisms”, then it simply means that we do not fully understand the relational data model.

    I think that’s what Fabian had in mind when he said that we do not know the relational model.

  21. anonymoron,

    Thanks for a well thought out response, excellent points on the current flaws in many SQL DBMS.. Given all that, do you know of any products out there that actually satisfy the term relational?
    What one’s would you say have gotten closest? What practical benefits/problems have you encountered?
    Any unusual different tools out there that you have come across that tackle the problems of data persistance/interrogration/manipulation/etc… in a different way? (frequently they are not what you want to use, but they can provide useful insights, in particular looking at why there is a perceived need for those kind of products)

    Oh, and fully agree on your points about having a decent understanding of the fundamentals is required (good analogy of designing a building or a surgical operation…).

    B

  22. Alphora’s D4 is a much more faithful implementation of the relational model. Unfortunately it requires a development stack that I do not utilize so I was only able to test the language independent from other ancillary components (jdbc, application development and the like).

    It still amazes me when the relational model is ridiculed for performance. Its a model, and as such, is mute concerning how one might implement it. It is because current implementations of the model (SQL) expose so much of the physical constructs in the language that they not only confuse users but lose independence from those constructs. I would point interested readers to the Trans-Relational Model to see how one might achieve orders of magnitude in performance gains over current implementations. (I cannot wait until this one hits the streets.)

    The beauty of the model is in its simplicity (For what is clear and easily comprehended attracts, the complicated repels, David Hilbert). However, just because something is intuitively easy to understand does not give practitioners liberty to mis-state and mis-interpret without recourse. The relational model is a way of representing data, with an open-ended set of operators for manipulating that representation and a way of ensuring that the data is consistent.

    “Storing data”? Again, the relational model is silent on this issue, and rightfully so! I really like the quote Codd had regarding this (paraphrasing) “If you tell me you have 50 ways of representing your data, I would say you have 49 too many”. Now, if under the covers you told me you had 1 or 1million ways of storing the data, who am I to judge?

    So, “Is the relational model of data storage the best, most effiicient way to store data?” I do not know, because “my” relational model does not tell me how it’s storing my data,and when I ask, it just looks back at me, smiles, and shrugs its shoulders.

    Annoying isn’t it.

    cheers.

  23. I think this discussion has some room to grow and some people that are interested, so despite its age, I’ll add my two cents’ worth.

    The initial question

    Is the relational model of data storage the best, most effiicient way to store data?
    is problematic. The relational model isn’t one of data storage; in fact, there are many (MANY) times I would have loved to have relations as first-class entities when writing Java code. They’re useful for describing data, in several contexts; programming and database are two near and dear to all of us.

    One of Relational’s practical virtues is in declarative integrity constraints. The practical value is immense; imagine establishing constraints that ensure your code is consistent with respect to its manipulation of data elements.

    The problems of a rigid data structure are partially due to poor DBMS tools; but many are inherent. Have you ever changed an XML schema and had to change code to match? How about a schema agreed upon with an outside party – layers of XSLT, anyone? There’s nothing wrong, and much right, with saying what you intend and then holding yourself to that; data structures and integrity constraints are meant to establish enforceable semantics – what you MEAN.

    When basic assumptions change, it’s not exactly unexpected that code you’ve written around those assumptions will change as well. In my opinion, compilers and IDEs and such make it easy to identify the implications; fully dynamic languages make it difficult, since in their pursuit of flexibility, they never hold you to any assumptions. Short-term ease; long-term risk.

    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.

    If all you want is “storage”, languages like Java offer serialization (to any Stream you like). Done. That doesn’t bother to constrain or structure anything; it takes whatever you give it. If no other applications need access to the serialized objects, and don’t care much about versioning and compatibility, then have at it. But don’t pretend it’s data. Data implies structure, type, and constraint.

    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?

    I agree that design and maintenance should be easier, and I think you’re implying a better integration between languages and relations (to the extent that you’re not talking strictly about SQL, which has only some of the benefits of relational).

    Relational data models are great reference implementations because all developers understand them.

    I wish this were true. I wish there were relational implementations developers could use (which requires that their employers embrace them). I do agree that relational is a reference for data models; OO and XML both stack up badly against the reference.

    /Eric

  24. 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

    This isn’t a hybrid at all; relational supports user-defined types, and XML could be one of those (I’d expect it to be). In fact, particular XML schemas are also types (since XML itself is really a type generator). Nothing hybrid about it; XML types would also support XPath operators (and perhaps XQuery, which is more of a report generator, I suppose). But can you imagine the pain of trying to say anything useful about acceptable documents, and their relations to other documents? Any enterprise will want integrity constraints; you can imagine the pain of expressing those in XPath expressions. So some of the XML will need to be converted to true data (relational attributes) to be useful.

    For most developers, the relational model taints our evaluation of anything else.

    No need for such rhetorical flourishes as “taints”; comparing models is useful, and certainly any comparison risks one comparand “tainting” evaluation of the other.

    … the first thing I usually do when I’m starting a project is build an object interface to my relational database.

    Presumably because you’re using an O-O language? In Java, for example, it HAS to be objects; you have no choice. C++ templates probably offer some respite from this; not sure about C#. Ruby on Rails shows some promise, in its language extensibility and database integration. But the common thread here is the quest for synergy between language and data model. Until relations are first-class language concepts (at which point, given constraints, they will push “objects” out of the nest), the impedence mismatch remains.

    BTW, what does your “object interface” tend to look like – does it treat the DBMS as an object, or attempt to map between SQL tables and your custom objects?

    /Eric

  25. where and how you persist data is often a very small part of an app.
    database theory is a small part of the entire application stack.

    “Small” measured how? In any event, relational is a DATA model, not a DATABASE model; it concerns DATA theory (akin to Type Theory), not DATABASE theory. And by “database” there, I assume you mean DBMS?

    Your application uses data from front to back. “Frameworks” provide architectural elements which apply to nearly any user-defined data; but most applications have business rules, and the vast majority of those concern data. Your application must manipulate data according to the rules; relational is all about defining those rules.

    I find myself thinking about how I can persist data given the tools I have and not piss Fabian off.

    Since he’s written several books with examples in SQL (not Tutorial D), guidance is clearly available.

    SQL databases have let me persist and retrieve data the way I have needed to for years.

    True enough, but needs aren’t the same as wants. All we “need” are files and machine code, right? We should aim for something better. Relational DBMSs will never get built if relational isn’t understood and desired. SQL succeeded wildly because it headed in the direction of relational, not because it reached the goal.

  26. True enough, but needs aren’t the same as wants. All we “need” are files and machine code, right? We should aim for something better. Relational DBMSs will never get built if relational isn’t understood and desired. SQL succeeded wildly because it headed in the direction of relational, not because it reached the goal.

    This is a good point, and since you approached it well and without insulting anyone, I completely absorbed it, and you’ve peaked my interest even more in “true” relational system.

    Take a cue from Eric, Fabian — being less of a jerk might advance your views quite a bit faster.

  27. Thanks – and for a good low-cost introduction, I’d recommend either (or both) of Chris Date’s new “Database In Depth” ($30 or so) and Fabian’s “Practical Issues in Database Management” ($35 or so). Date’s Introduction is great but massive; I enjoyed it, though most just won’t buy a book for $100.

    Also good is The Third Manifesto – a good discussion of how type theory plays in relational. More cogent than most OO books.

  28. Fabian,

    i see that you are busy scanning through all forums just to be able to say people have got it all wrong… but i have some simple questions about this TRUE relational model you are taking about

    1. can it support partial knowledge eg. a value > 10, so constraints instead of actual values
    2. can it mix derived facts and give facts
    3. knowledge engineers have moved to frame based, description logic based systems because pure logical statements become managebility
    4. does it have a proper way of handling temporal-fluent informations the difference between stateful and stateless concepts, etc…
    5. would you store the information of a spiking neural net in this relational model :)
    6. would you store source code in this relational model….
    7. does it improve communication of an information model
    8. can it express constraints over the number of relations between instances (higher order logic)
    9. ….

    right know the relational model (at least as implemented in the current DBMS systems) is only useful for applications not beyond a certain complexity in terms of what an application using the data can do

    so i think you are missing a big point, namely that a ‘datamodel’ is only there to support some application function be it workflow, transaction processing, document handling, business intelligence… so with the current state of the relationmodel i would not try to sell it as the ultimate tool for everything nor is a datamodel which support every possible query one can image really useful, it is sometimes better to have a model which can support some queries very well, and the physical ‘tuning’ clustering … of a database cannot always solve these problems

    conclusing: use the right tools for the a particular job and don’t try to sell the relation model is the ultimate solution for everything

  29. A Relational database consists a set of tables, where each table consists a fixed collection of columns. The relational model is the first formal data model. A relational database consists of tables. Each table describes the relation of the main subject of the table to important information. The relational model of data permits the database designer to create a consistent, logical representation of information. here are many advantages of the relational model over the other models, which is why the most popular databases in use today employ this methodology.

  30. Fabian, I am in a workplace where lack of knowledge seems king and from reading most blogs it seems to be pervasive. Arguments are stated by those who are planning to architect or design a system but appear to lack the knowldedge in data modeling or database technology that is required. They want to develop an application! To them, the application is important, not the data. They want to promote generic tables or simply stuff XML into the database. They want a bag to persist data and a hash table of hash tables. they don’t want an RDBMS and they don’t see the need to define data. I believe the educational system has failed to teach and promote a mature understanding of software and OO development. Redemption is lost to them when the norm is opinionated comments from those who have failed to properly research a matter and tend to unquestioningly jump on marketing bandwagons without using common sense. (Java runs everywhere right?) Rational decisions are impossible without rational discussions. The statements made quickly tell a persons character, knowledge and experience … or lack thereof. I fell in love with OO and Java in 1998 and became Sun Certified soon after when it required you pass an exam with > 70%. I also immediately saw the value of XML as a great way to import/export data (But I still fail to this day to see its value as an applications internal data store for anything more than small property configuration files). Yet, it seems many developers with a mix of Java and XML training still lack understanding of what an RDBMS is. To them, the database should be emasculated of all logic and serve only as a persistent store (no constraints, no structure, no logic, just a generic table of tables or maybe on long string of parseable data). Of course object rehydration and type system is possible with generic table of table design, but this design will obfuscate, complicate and impaire access. What screams at me is they do not want to do the work they are hired to do, which is analyze the business requirements and design a system – coding is easy. Watch out for eXtreme Programming being used here as a poor excuse for this prescribed approach or the defence that its a very flexible system. Truly in the end, what you find is an overly complicated data access layer that performs poorly because nothing is typed or structured in a way that speaks directly and cleanly for itself, it is difficult to maintain and fails to provide superior or scalable peformance. And if I suggest that the root of the problem is a lack of a consistent architectural application of the OO model they are immediately up in arms. They do not seem to see that an RDBMS should be treated as any first class OO citizen having full authority over and fully encapsulate its own state behind public interfaces (stored procs) which define behaviour (yes that’s right – data encapsulated with code) and any application wanting to use it must respect and adhere to the interfaces it defines (not the otherway around). This would mean no private RDBMS internal sql methods such as no direct ddl, insert and update sql type statements allowed. To me, OO by its nature adds value because of its tightly typed model (everything is a type) and not its lack of it. Good OO code isn’t represented by code full of references to objects, its code that defines and references specialized types. OO is wonderful when you can ask, question “like what are you and what do you do?”. Now if you design a hashtable of hashtables or make every datatype a string, you have lost this OO concept To obtain low coupling and high cohesion, types must be well defined. So why would a developer not think the same should also be applied to a data store? Why do we understand aggregation and containment for complex objects but a database is considered more like a native string object with public access. Why is a true OO approach to the Database less understood and accepted than it is with any other application’s API? The truth is there is a historical problem here. Developers like to code, not design and document. I don’t know of many systems that fully adhere to the above approach and therefore the RBMS is often abused. This problem bubles to the surface in the RDBMS in many forms just as it has in earlier applications. A good illustration of this is the sql injection security issues prevalent in many applications. In best of breed OO, if you need a collection of objects, you shouldn’t represent it as a hashtable or vector type. Instead, you first define a specific user type whose type name speaks to your domain and internally define its structure using what ever type you find necessary for implementation. This provides proper OO type classification and clearer code understanding. In reality this is not adhered to with most Java or OO development – effort, time and speed are what often weigh in here and I also am guilty of this. Faster is better isn’t it? Does operational integrity and maintenance have a voice? The code I am most proud of producing is that which I have had the opportunity to invest adequate upfront time in analysis and design. The result is an implementation that includes object reuse and the continued ongoing development, testing and deployment is made easier and faster. In every case this required more understanding of the problem, better definition of the domain and required more design of structures and protocols – not less. Unfortunately the rebuttal I often receive is “You don’t understand, if you knew anything about OO, ORM, impedence mismatch and new technology or methodologies…” Sadly, in my workplace patience is a virtue and I must exercise it more often than I get to exercise discussions on rational or logical design.

  31. Fabian, I am in a workplace where lack of knowledge seems king […]

    TR, I write on a blog where people think the subject of a post is actually the author, and that they can write him back here…

  32. To Fabian: The “true” relational model may be good. But in practice web-app developers seek for solutions which are good enough, according to their needs.

  33. As comments on this topic has been closed, I reply here…

    Fabian, you’re telling us everywhere that all the world is wrong about RM. OK, I can agree with that, RDBMS are not ideal implementations of the RM. But you never really told us why the existing solutions are bad, what exactly do they do wrong, and the most important: what we could benefit in practice from knowing the “One True and Real” Relational Model? Would our apps performing better? Taking less space? Being more stable? What’s the real benefit besides the “pride” of being more educated than others? If there’s nothing to benefit in practice, then the knowledge is also worth nothing, only a brain-stuffer.

    And one more thing: When I see that someone is less educated in some area, or doesn’t know something that I know, I’m trying to give him some of my knowledge to change that inequality. But for you it looks like a level of education is only another reason for discriminating and insulting people, because it’s the only thing you’re doing in that matter. So let me tell you something: That way you won’t change anything except your reputation.

  34. SasQ, you apparently aren’t familiar with the many excellent articles, papers and books that Fabian Pascal has written on precisely that topic. Pascal has made a very significant contribution to educating people about the relational model and about the problems with the SQL model. There would be no point in him repeating himself here but please take a look at his books, which you can find on Amazon.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.