Re: Mixing OO and DB

From: Patrick May <pjm_at_spe.com>
Date: Sun, 10 Feb 2008 10:19:49 -0500
Message-ID: <m2fxw0susq.fsf_at_spe.com>


frebe <frebe73_at_gmail.com> writes:
> On 10 Feb, 00:18, Patrick May <p..._at_spe.com> wrote:
>> >> 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".

     That still leaves a window during which the data can be out of date. It also imposes certain performance costs that may or may not be acceptable.

> Having a denormalized schema is also a good way of introducing data
> that is out of date.

     How so? Regardless of the normalization of the schema, operations should be ACID.

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

     As I pointed out, even with a database used only by a single, albeit distributed, application, there are reasons for the schema to change that do not require existing behaviors to change. Similarly, there are behavior changes that do not impact the schema. This is even more prevalent in databases used by multiple applications.

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

     Do you have a reference to this technique being used in practice? I'd need to see the details to understand what you mean.

Sincerely,

Patrick



S P Engineering, Inc. | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm_at_spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Sun Feb 10 2008 - 16:19:49 CET

Original text of this message