Re: Mixing OO and DB

From: frebe <frebe73_at_gmail.com>
Date: Sat, 9 Feb 2008 22:07:35 -0800 (PST)
Message-ID: <92743840-1a8a-4b1e-84e9-3eb2f6ae29df_at_e10g2000prf.googlegroups.com>


On 10 Feb, 00:18, Patrick May <p..._at_spe.com> wrote:
> frebe <freb..._at_gmail.com> writes:
> >> >> Even when the relational schema is embedded in a single
> >> >> application, state changes for different reasons and as
> >> >> different rates from behavior.
>
> >> > Would you mind giving examples of such changes? (You can skip the
> >> > "denormalisation for performance" example.)
>
> >>      Denormalization for performance of a particular application is
> >> a perfectly valid example.  
>
> > Unless your database supports materialized views.
>
>      And if your application can accept that the data in those views
> may be out of date.

Unless you do "refresh on commit".

Having a denormalized schema is also a good way of introducing data that is out of date. It is also an advantage if the RDBMS can handle the consistency issues. If you try to handle them by yourself, it is more likely that it will fail.

>      With a single application database, distributed applications
> demonstrate additional trivial scenarios.  A new service or agent
> might need data that is not of interest to existing services and
> agents.

The reason why the schema change is that the behavior change. Behavior and schema doesn't change for different reasons.

> >> >> > Maybe somebody may suggest me some article about mixing
> >> >> > together DB and OOP?
>
> >> >>      Because of the impedance mismatch, most OO systems use some
> >> >> form of object-relational mapping.
>
> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >>      What alternative do you recommend?
>
> > My recommendation is that if you already are using a database, you
> > should not use objects as data structures. That is job is supposed
> > to be done by the database.
>
>      So your answer to the question "How do I mix OO and relational?"
> is "Don't use OO."  Succinct, but not particularly responsive.

I didn't say that. Like I said before, classes may perfectly well be used for defining types for relational attributes. Objects map to attribute values, not to relations.

//frebe Received on Sun Feb 10 2008 - 07:07:35 CET

Original text of this message