Re: Mixing OO and DB

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

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

     Actually, it's the behavior that's the foundation of the application. A relational schema may not be necessary at all or may be simply an implementation choice.

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

     In addition to denormalization for performance, examples where the database is shared are trivial to find. Not all applications change at the same rate, so not all applications need the same schema changes.

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

     Some may be involved in addressing NFRs such as performance, scalability, high availability, resiliency, and so forth, certainly.

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

     That sounds closer to a definition of "expressiveness".

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

Sincerely,

Patrick

                       | systems design and implementation.
          pjm_at_spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)