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

Robert Martin wrote:
> On 2006-06-02 09:06:56 +0200, "Marshall" <marshall.spight_at_gmail.com> said:
>
> > Robert Martin wrote:
> >> On 2006-05-31 12:44:04 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
> >>
> >>> Wow, I missed that one completely. "Isolate the data management
> >>> mechanism from the data model." How in tarnation is the data
> >>> manager doing to manage the data if it is isolated from the
> >>> data model?
> >>
> >> It's called decoupling. Generally it's based on dynamic polymorphism
> >> which is a lot of syllables that really mean function pointers. The
> >> idea is that you write the application program in such a way that it
> >> can manipulate the data in the data model without coupling it directly
> >> to the DBMS, or the details of the schema. The decoupling mechanism is
> >> very similar to the mechanism used to create device independence in
> >> operating systems like Unix.
> >
> > That's a complete non-sequitur from the sentence I took issue with.
> > You said, "Isolate the data management mechanism from the data
> > model." This has a very clear denotation: it means the dbms should
> > not know the schema of the data it is managing. This is clearly
> > self-contradictory. Perhaps you didn't mean that? Perhaps the
> > later "it's called decoupling" paragraph is more like what you
> > really meant to say?
>
> Yes, I think we have a vocabulary problem. Sorry. What I want to
> separate is the application code, and it's internal data models, from
> the DBMS and the schema.

Okay. Applications might need their own physical data structures; sure. But their *logical* data structure needs can be met *directly* by the dbms.

Marshall Received on Tue Jun 13 2006 - 19:52:54 CEST