Re: Mixing OO and DB
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 05 Mar 2008 11:50:39 -0400
Message-ID: <47cec154$0$4062$9a566e8b_at_news.aliant.net>
>
> You make some good points, but there's another one you
> didn't mention, and that is that manual denormalization is more
> error prone. You have to get it right everywhere you do an
> update, and that's not just in code. Also doing it manually
> means that every relevant programmer has to know the
> protocol, and follow it without mistake, every time, instead
> of just declaring the intent and letting the computer handle it.
Date: Wed, 05 Mar 2008 11:50:39 -0400
Message-ID: <47cec154$0$4062$9a566e8b_at_news.aliant.net>
Marshall wrote:
> On Mar 5, 6:21 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>
>>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.
>
> You make some good points, but there's another one you
> didn't mention, and that is that manual denormalization is more
> error prone. You have to get it right everywhere you do an
> update, and that's not just in code. Also doing it manually
> means that every relevant programmer has to know the
> protocol, and follow it without mistake, every time, instead
> of just declaring the intent and letting the computer handle it.
Unless, of course, one declares the necessary constraints, in which case the supposedly faster solution will be much, much slower. Received on Wed Mar 05 2008 - 16:50:39 CET