Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Marshall wrote:

> A DBMS is not "storage." A DBMS is a system that manages
> data, where "manages" describes a whole host of high level
> facilities.

That's no excuse to couple with it.

Define "coupling" as "A must change for no other reason than B changed". Define "cohere" as "A and B share reasons to change".

In the ideal situation, most changes in one module don't ripple into another. Coherent changes represent adding a feature to A such that B indeed upgrades to support its part of the feature. The change to B wasn't just adjusting to A's new feature; B gets more value.

An example of coupling: Table Q gets a new join, to Table J. Now I must go to the application code and start throwing away J records, because the data queries now get them. (I'm aware joins don't automatically do that; it's just an example.)

An example of coherency: Field Q:N was an integer, now it's a long. I must also change copies of N in the application. Both fields now have more value - they can store more numbers. So Q:N coheres with application variable N.

> The c.o. people's arguments are mostly based on the false
> premise that a DBMS is a kind of storage mechanism.
> Once you accept a false premise, you can prove anything.

If the data store were very dumb, such as XML, "we c.o people" would have _less_ problem coupling to it. It's _because_ the DBMS is very smart that the risks from coupling gets so high.

-- 
  Phlip