Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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: Marshall <marshall.spight_at_gmail.com>
Date: 2 Jun 2006 19:55:05 -0700
Message-ID: <1149303305.391715.158460@i40g2000cwc.googlegroups.com>


phlip wrote:
>
> 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.

In an ideal situation, most changes in the *implementation* of one module don't ripple into another. If a module changes its interface, then the changes necessarily ripple into other modules that use it.

JDBC and SQL won't be changing in a backward-incompatible way, so that's not an issue. And the database schema *is* the interface to the database, so any changes there necessarily ripple.

If the implementation of the dbms changes, you'll won't see any rippling.

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

Huh? You admit that you're describing something that doesn't happen, but it's an example of something?

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

You have described a schema change.

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

Okay. So the dumber a service is, the more okay it is to use it various places in your app. But if a service is smart, you really want to pidgeonhole it; limit the scope of its use.

Do you see a problem with that?

Marshall Received on Fri Jun 02 2006 - 21:55:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US