Re: Normalization and Derived Information

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Sat, 2 Oct 2004 07:17:56 -0500
Message-ID: <cjm69p$6p9$>

"Kenneth Downs" <> wrote in message
> Laconic2 wrote:
> >
> > "Kenneth Downs" <> wrote in
> >
> >
> >> Since a view generator is a special case of a SELECT generator, my
> > thinking
> >> runs towards using materialized derived columns in tables, so that the
> >> selects are always pulling simple columns and never calculating on the
> > fly.
> >
> > Yup, a SELECT generator. Cool!
> >
> > Another question is WHEN to do the materializing: at store time, at
> > retrieval time, or some time in between.
> >
> > The same question occurs in compilers. There are some compilers that
> > smart enough (or dumb enough) to
> > evaluate sqrt(2) at compile time, and merely store the result in the
> > object program, much as if it had been a literal in the source.
> My current thinking, which I am implementing in my current project, is to
> materialize in the INSERT and UPDATE triggers. This is not to say there
> are not other ways, but in this way the definitions are satisfied within
> the transaction. There will be howls of protest about performance, but
> methinks the CPU time on the server to generate the value is less than the
> wire time to send it over from another tier (I could be wrong).

I could be missing something, but the only way there would be howls of protest would be if you decided to materialize the values synchronously, right? I can see reasons to update data synchronously, but no reason to maintain materialized derived data while a user waits. Triggering an asynch processes would make more sense, I would think. Again, maybe I'm not understanding either your requirements or your design. Cheers! --dawn

> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "" to
> email me
Received on Sat Oct 02 2004 - 14:17:56 CEST

Original text of this message