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: Fri, 02 Jun 2006 13:10:22 GMT
Message-ID: <2NWfg.45053$Lm5.29220@newssvr12.news.prodigy.com>


David Cressey wrote:

> I'm lost with "conceptual distance".

Google "separation of concerns".

> Here's a scenario. We look at four modules (out of hundreds) in a large
> hospital data magement system.
>
> One module massages data about health insurance, credit cards, and
> reimbursement. It is written in Java.
> A second module exchanges data with the DBMS about health insurance,
> credit
> cards, and reimbusement from the . It is written in SQL, with a thin
> wrapper of Java.
> A third module exchanges data with the DBMS about clinical histories,
> patient privacy, and compliance with privacy law. It is written in SQL,
> with a thin wrapper of Java.
> A fourth module massages data about clinical histories, patient privacy,
> and compliance with privacy law. It is written in Java.
>
> It sounds from what you've said above as though the "conceptual distance"
> between modules 2 and 3, and between 1 and 4 is short, while the
> "conceptual distance" between modules 1 and 2, and between 3 and 4, is
> long.
>
> This makes no sense to me.

All four modules need high-level objects, and they need persistence, so these objects have the right state.

(All three modules don't communicate directly with each other, so your 2->3 and 1->4 pairings have the best kind of interface between each other: None.)

The objects themselves need a database, to supply the persistence.

So all four modules work with business-level concepts, the persistence layer works with raw data value concepts, and the database works with business level concepts, in a different format.

Something must translate formats into those convenient for each module. Suppose a patient history stores in the database as a sequence of dated events. And a given module only needs a certain subset of patients and dates - a different concept. So the conduit between the two concepts should be relatively narrow. The module should not concern itself with excess records, just as the database should not store every kind of query as a separate table.

Oooh you said some of the items are written "in SQL", meaning one of the stored procedure languages. Same difference; they use views to narrow their interfaces.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Received on Fri Jun 02 2006 - 08:10:22 CDT

Original text of this message

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