Hi all!
Todd Blanchard tblanchard@mac.com wrote:
Funny, I just blogged about this.
And a "response" from me:
http://goran.krampe.se/blog/Bits/ODBvsRDB.rdoc
But... let me ramble a bit about the RDB life cycle stuff.
JJ IIRC talks about making a "proper" relational model and then letting multiple apps written in various languages over time operate on it - or parts of it. The idea is that the data "lives forever" and the apps come and go.
Is this idea really based on real world observations? I dunno, I have only been exposed to a few "enterprises" so my experience is of course not valid for proofs but I have a feeling that it goes more like this:
1. Someone builds an app. Or hey, the company buys one. A big business system, or whatever. It has tons of interesting data in an RDB. It is not object oriented and it has few or very bad interfaces to the outside world.
2. Another app, bought or homemade wants to use that data - or even manipulate it! Noone at the company has ever thought of the concept of encapsulation - so what the heck, let's go straight to the source - use SQL right into the RDB - these table and column names don't look so hard to grok... For readonly queries we will hopefully get it right, for manipulations we damn sure *hope* to get it right.
3. And yet another apps pops up putting its fingers in the cookie jar too and so it goes. Eventually we have tons of apps written in a bunch of languages using/abusing the RDB, adding tables of their own, breaking a few rules here and there perhaps, not using the proper SQL and so on. It might be tempting to say this is BY DESIGN and that this is GOOD, but I think that is often a reconstruction of the truth.
I also don't think that first app ever really dies without the DB going down with it. I also don't think you *first* design the DB, then build apps to use it. Nope, it is that first app that comes with the DB and the DB can't just stand on its own without it. Sure, you might *rewrite* that app using the same DB - but have you ever seen that being actually done? Some of the apps that came afterwards may go, but the original system typically is only *replaced including the DB* with something else when it gets unbearable.
Using the RDB as a sharing ground for applications is IMHO really, really bad. Sure, it *works* kinda, but very fast you end up with replicated SQL statements all over the place. Then someone says "stored procedures" and hey... why not consider OBJECTS? There is probably a reason why people are so worked up about Services these days. :)
Just my 3 cents of course.
regards, Göran
PS. On a given day and context lots of factors come into play. I just don't buy simple answers about RDBs being superior for enterprises based on these particular arguments. There are large mission critical systems built using ODBs running at "Enterprises". If it fits they rock.