Re: Mixing OO and DB

"Patrick May" <pjm_at_spe.com> wrote in message news:m263w2kwrc.fsf_at_spe.com...
> "Brian Selzer" <brian_at_selzer-software.com> writes:
>> "Patrick May" <pjm_at_spe.com> wrote in message
>> news:m2bq5xylnc.fsf_at_spe.com...
>>> One common denormalization technique is to eliminate a join by
>>> adding columns to one table that replicate data in another table
>>> that has a one-to-many relationship with the table being
>>> denormalized. The business logic shouldn't have to change just
>>> because the schema does.
>>
>> Why denormalize when you could just use a materialized view?
>
> Materialized views are not always available and may not provide
> significant performance benefits if the data is being updated
> frequently and the clients need the absolute latest values.
>

How is that different from denormalization? Updates still have to be made in a denormalized schema. Of course, instead of updating one row, it may be necessary to update hundreds or even thousands of rows due to the redundancy inherent in a denormalized schema. With a materialized view, those updates become a refresh of the view, which can happen independent of the update. The only substantive difference I can see here is that queries can still be satisfied by using the base tables while the materialized view is being refreshed, but with a denormalized schema, queries must be held up until those hundreds or even thousands of rows are updated, assuming, of course, that clients need the absolute latest values.

I guess it could be that due to the frequency of updates the materialized view could be stale more often than not: in that case there wouldn't be any point in materializing it. But I don't see how a denormalized schema would work any better, since much of the time queries would be waiting for update transactions to complete.

> Regards,
>
> 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 Wed Mar 05 2008 - 15:21:15 CET