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: Phlip <phlipcpp_at_yahoo.com>
Date: Sun, 04 Jun 2006 17:17:45 GMT
Message-ID: <ZAEgg.110985$dW3.68290@newssvr21.news.prodigy.com>


frebe73 wrote:

>> Could you state back the claim you feel is unsupported?
>
> "If you ever need to make structural changes to your data model inside
> the DBMS, changing your applications is easier."

I think that just means "Encapsulation". How could one support a claim of Motherhood and Apple Strudle??

>> Per the general thread, it means maybe data X comes from a DB, and data Y
>> comes from a flat file, and they both come thru the same interface, so
>> the
>> business logic that adds value to them can't tell where each came from.
>
> What are the benefits doing this? Why would you use flat files if you
> already have a SQL implementation? Why would you use SQL if you already
> have a flat file implementation?

That's a different question. Maybe the customer ordered us to put Y in a flat file, so they can write on it with their favorite text editor. Or what ever. The question is not Why should we sometimes not abuse our database. The question is How to encapsulate the business logic so such decisions are less relevant to it.

>> If you need data, you should get it from whatever system, thru a common
>> interface. The alternative taints business logic with runaway
>> dependencies.
>
> That is why we use common interfaces such as JDBC/ODBC/ADO.

Those are wide generic library interfaces. Once we have them, we trivially encapsulate them again, into narrow application-specific interfaces. We take one more step towards programmer-friendliness because those wonderful libraries can't.

>> > Lets say the original table looks like this:
>> > client(clientid, ...., domicile)
>> >
>> > Your change need a new table:
>> > client_domicile(client, domicile)

> So you agree that in this example, decoupling the SQL statements would
> not make the change easier?

Gee, much of the decoupling will already occur at the generic library interface. So how about _this_ change:

client(clientid, ...., domicile) -> client(clientid, ...., domicilio)

After that change, the more lines of application code I must change, the more coupled that application is. The fewer, the better.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 
Received on Sun Jun 04 2006 - 12:17:45 CDT

Original text of this message

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