Christopher Warner

So, for those of you that are aware of my work woes we are going to go back to some conversation on Object Databases and why as far as Content Management it only makes sense in this the year 2009; and it’s really easy stuff! First read this (I did a quick random search for Object Database FAQ’s and found this paper published in 2001). “Why Aren’t You Using An Object Oriented Database Management System” …… The closest thing the hordes have been using to something rational is SQLAlchemy which django, ror and all of the other popular kit are using now. Obviously you still have the overhead and the same issues exist but people seem to actually like writing out mappings to a relational database so that they can reap the benefits of an object database. If that’s the case, why not just use an object database? Please don’t say legacy to me; please. Basically SQLAlchemy is what we would call GLUE it’s just mapping your objects into objects in the database! Sooo ummm, why all the extra work and overhead? I don’t know… So since it’s 2009 and that paper was written in 2001; and there are older papers that ask why people still using Relational Database systems explicitly for stores when they are clearly using object-oriented everything else. I’m going to state that if you aren’t using an Object Database for a new web application.. You are doing it WRONG! All of you Web 2.0 people, can you catch up pleaseee; I am speaking to you, it’s 2009 and you are holding people like me back having to interoperate with your 1990’s, 20th century mentality. On the business side it’ll save money and make reporting SO; MUCH; EASIER, so please.. catch up to the rest of us or at least sit down with your DBA (you do have one of those using a relational database system right?) and start normalizing your data and relationships.

So onto my current nonsense. I am having to deal with a bunch of what are termed “listings” in a sql database that are representation of an object in the actual sql. It looks like this:

 

Hello, this is 1992, we'd like our SQL back

Looks, like crap you say? Yes I agree, now click on that link to get a fuller view and lets look at some of these columns. We have the “class” column, the “ord” column and the “data” column. These are the only thing we need to be concerned with. In the class column we have the variables that what would be what a full listing object is made up of. In the ord column we have the order these values appear in the object.

“Seems a little weird, why would you want to change the order of a “class” or the items in your object” Originally for display issues, but editors like control over the object display in edit.

“Isn’t that kind of a display visual issue though, actually doing that in the object is kinda retarded Chris, I know you had nothing to do with that” Yeah it is but this was done a long time ago and I had nothing to do with the design but this is what we have; stop interrupting me. I know all of that stuff already

Then we have the data column which is filled with the actual data associated with a variable in the actual listing object!

“Ahh, wait, but isn’t that like PERFORMANCE FAIL! That can’t possibly be a good thing, how does that stuff get updated?!” Can you please.. PLEASE.. PLEASE.. stop interrupting me.. This isn’t my first time looking at this ok.. Just.. ok?! Thanks.

So, obviously you pointed out some of the obvious things but lets point out some of the things that you may not realize. First and foremost all of this data is in one table. Not one table per object but all in one big table!! So one has to obviously have primary keys to get to this data which is stored in another table and you guessed it. There are lots of joins and other things going on here that aren’t pretty.

“Wow that sucks ass!”  Last time man, last time.. gotta stop interrupting me but yes, it does suck ass.

“Wait, one thing… What are all those funny numbers in data at the bottom?”  Oh yes, those numbers.. well those are relationship id’s to other data separated by the pipe char.. “Ummm but you are using a RELATIONAL database and aren’t even taking advantage of the relational features?! WTF?!”  Ok? Seriously…?!? I KNOW ALREADY.. Let me finish.

Mannn, anyway some more problems with this setup are what happens when your data schema changes and you have a new attribute or piece of data in the overall model?  Well, we just read one of the draw backs in Object Databases is that you have to go back and update every thing; well if you store everything in a table like this you have the same exact problem!! Except it’s even worst here because you aren’t just updating a table schema you have to actually find the type of object based on actual data in the table. That’s not fun; or efficient. 

The drawbacks are many, hard to pull data out of the RDBMS; if something is updated going back and reindexing EVERYTHING and updating EVERYTHING to get the new schema and god forbid you make a mistake. Which humans are known to do and we begin to get a DBMS that is pretty difficult to deal with. Now because we aren’t all DBA’s (which is why a good DBA is worth his or her weight in gold any day of the year) or have foresight that of a prophet (no one can see the future right) and because hindsight is 20/20 would it not make more sense to have your objects; in lets say an object database? We have to rapidly deploy and prototype web apps and programs that are going to quickly become “production” applications. Unless you have the DBA or can afford to call one in every time you change your data model it doesn’t make sense ok? It doesn’t. If later you find that your objects and their relationships can be static enough to put in a relationship database model then more power to you. Of course there aren’t any major benefits I can think of if you are dealing with large amounts of data. Back in the day MySQL made sense because it wasn’t ACID in anyway so you got speed there but as it has grown and people have come to rely on it, those features are there now. So, you won’t be getting speed benefits there and any speed benefits you would like to see simply need a custom solution anyway; most likely involving cache etc etc.  

So Web 2.0 meet 2009, 2009 meet all of my Web 2.0 people or whatever they are calling themselves.. Please, get acquainted before the decade closes..

This entry was posted on Tuesday, March 3rd, 2009 at 6:44 pm and is filed under Advogato, Commentary, Opinion. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.