Re: trigger fired on changes in specific column

On Fri, 23 Aug 2002, Richard Huxton wrote:

> However, I think you need to look at your data definitions - this sound
> horribly unnormalized. I'm not a normalisation fascist, but this just feels
> *very* wrong.

Well, the values are redundant and calculated from other values in the
table. It used to be in a view calculated from the rest. But the
calculation takes a lot of time so I have to store it somewhere.

The problem is that the calculation formula gives that when I change one
value in a group all the calculated values for the group have to be
recalculated.

Before I added these calculated values the database was in BCNF. Now it is
not, but it will not really change anything if I keep these values in
there own table or not.

> Is there a good reason why you don't decompose B,C etc to their own tables and
> join where necessary. You can probably keep things looking the same (or at
> least very similar) using an appropriate view.

I can do this (and probably will), and what it helps me is just so the
triggers works (esier). It does not really change the problem of storing
redundant data in the database. But the world is not perfect, I have to
precalculate and store these values or it is to slow.

I think your recomendation is both valid and good. If I could find a
better way to handle this I would. Maybe something like a view that caches
values or something, but I have not found that in postgresql.

--
/Dennis