Re: Mixing OO and DB

From: frebe <frebe73_at_gmail.com>
Date: Sat, 9 Feb 2008 08:50:59 -0800 (PST)
Message-ID: <2c1e5f77-55b2-43ee-ac8b-ba2ee12512fd_at_v4g2000hsf.googlegroups.com>


> >> 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.

> Another reason
> for the different rates of change are that new behaviors can be added
> without the need for additional data.

Yes, pretty obvious. The schema is the foundation of the application. There are many reason to change the application stack on top of the schema. But do you have some example of a schema that need to be changed, and the behavior doesn't need to change?

> >>      The object model, on the other hand, is optimized to address
> >> non-functional requirements (NFRs) related to the problem domain.
>
> > Doesn't that indicate that OO is pretty low-level, and that the
> > coupling between the logical model and the phisycal model is high?
>
>      Not at all.  OO supports the creation of abstractions that
> represent concepts in both the problem and solution domain.

And the abstractions for concepts in the problem domain doesn't have to be optimized to address non-functional requirements?

>      The terms "high level" and "low level" tend to be more pejorative
> than descriptive in these discussions.  They make sense within a
> particular paradigm, but generate more heat than light across paradigms.

I might have a naive definition of "high level" and "low level": If you implement a solution using two different tools, the solution that has less lines of source code and takes less time to implement, is the most high-level.

> >> > 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.

//frebe Received on Sat Feb 09 2008 - 17:50:59 CET

Original text of this message