Re: Mixing OO and DB

From: Patrick May <pjm_at_spe.com>
Date: Thu, 06 Mar 2008 22:21:56 -0500
Message-ID: <m2y78vfcbv.fsf_at_spe.com>

"Brian Selzer" <brian_at_selzer-software.com> writes:

> "Patrick May" <pjm_at_spe.com> wrote in message news:m263w2kwrc.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.

     With a materialized view, the updates to the underlying tables

need to be propagated to the view at some point. If updates are frequent and the clients of the materialized view need the latest values, this is an extra step.

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

     Exactly.

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

     You'd save the time required to update the view. Depending on the granularity of the update, you could get some performance improvement when the query is for rows not currently locked under a transaction.

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 Fri Mar 07 2008 - 04:21:56 CET