Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Bob Badour <>
Date: Fri, 02 Jun 2006 22:33:10 GMT
Message-ID: <G03gg.16679$>

phlip wrote:

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

Given the power and elegance of the relational model for providing different views of the data, the data management system already provides a far more powerful mechanism for decoupling than any provided in OO.

If the data to be managed truly changes, then the application will need to change regardless.

> Define "cohere" as "A and B share reasons to change".

Pretending an english word means something different after the fact does not accomplish anything useful. From

co·here (k-hîr)

v. co·hered, co·her·ing, co·heres
1. To stick or hold together in a mass that resists separation.
2. To have internal elements or parts logically connected so that 
aesthetic consistency results: "The movie as a whole failed to cohere" Robert Brustein.
To cause to form a united, orderly, and aesthetically consistent whole. [Latin cohaerre : co-, co- + haerre, to cling.]

More relevant to this discussion, see:

Arbitrarily grouping database access together has very low cohesion. See coincidental cohesion at the wiki link above.

[incoherent, unecessary and ironic attempt at remedial lessons in cohesion and coupling snipped]

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

Is that an argument for hiding your OO code from the assembler code you write you applications in? After all, if the OO code were just more assembler code, your assembler code would have fewer problems coupling to it. Right? Is that the point you are trying to make to us?

I suggest you learn what a premise or an axiom is. If your axioms are false, the conclusions you derive from them are worthless and the derivations pointless. Received on Fri Jun 02 2006 - 17:33:10 CDT

Original text of this message