Andrew,
> Sure, but if performance is an important goal for certain kinds of
> SELECTs, using a trigger at insert or update to do denormalising is
> perhaps an acceptable approach. It's obvious that in most cases,
> denormalising instead of optimising your normalisation is silly. But
> if you need something to return in, say, 2ms most of the time, and it
> requires a wide variety of data, denormalising is a good idea.
I've done this plenty of times ... but what you're talking about is more of a
"materialized view" than denormalized data. The data is still stored in
normal form; it is just distilled for a particular view and saved on disk for
quick reference. This is often a good approach with performance-sensitive,
complex databases.
> It is, of course, contrary to the RDBMS-y mind to denormalise. But
> there are (rare) times when it's a good idea, and I hate to see it
> rejected out of hand in such cases.
There is a big difference between denormalizing normalized data and storing
your data in denormalized (basically flat file) form in the first place.
--
-Josh Berkus
Aglio Database Solutions
San Francisco