Hi all!

Todd Blanchard <tblanchard at mac.com> wrote:
> Funny, I just blogged about this.
> 
> http://www.blackbagops.net/?p=93

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.