Re: Mixing OO and DB

mAsterdam wrote:
> Patrick May schreef:
> > mAsterdam writes:
> >> Patrick May wrote:
> >>>>> If the application implements the solution using a DAG, for
> >>>>> example, and the state of each node in the DAG is stored in a
> >>>>> relational database, then a mapping between the two models must
> >>>>> take place.
> >>>> The data is regrouped. Not a huge decoupling, but yes, more than
> >>>> just aliasing.
> >>> It's more than regrouping. A different set of behaviors (graph
> >>> traversal, etc.) are being supported explicitly.
> >> From the behaviour POV (point-of-view) there is some decoupling
> >> (effort /and/ gain), but it is completely done within the
> >> behavioural realm, not at the border (the schema). The set of
> >> behaviours is not relevant to the data itself to begin with, so from
> >> the data POV no decoupling is gained at all.
> >
> > I think we might have the same disconnect that Mr. Selzer
> > identified. I am using the word "schema" to refer to both the data
> > and the data structures that hold it. Are you using that word to
> > refer to the data only?

>

Its a matter of interpretation. It can be seen in terms of an interface, which is a set of conventions. One can also think of it as a physical "structure", but that is not the only way.

The issue is that OO'ers often don't like the relational "interface" because it is not OOP, and thus want to wrap it with an interface of their own. It is *not* "hiding the hardware layer", though, as some OO'ers claim or suggest, because RDBMS are not hardware, nor "low level".

In my opinion, wrapping the RDBMS all the time is usually not a good thing because it merely translates between paradigms rather than adds anything real. It just complicates the project to translate back and forth between two high-level conventions, like a butler carrying handwritten  messages back and forth between a fighting couple.

-T- Received on Sat Apr 05 2008 - 01:29:07 CEST