Re: Mixing OO and DB

From: Brian Selzer <>
Date: Wed, 5 Mar 2008 09:21:15 -0500
Message-ID: <v%xzj.61121$>

"Patrick May" <> wrote in message
> "Brian Selzer" <> writes:
>> "Patrick May" <> wrote in message
>>> 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.
> | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Wed Mar 05 2008 - 15:21:15 CET

Original text of this message