Jim,

>Normalization optimizes for insert and update activities at the cost on the retrieval side of things. I denormalize when retrieval is more important than update and insert. I also NEVER denormalize before having reached a fully normalized design. Denormalizing is an active not passive process and one cannot actively denormalize something that was never normalized in the first place.

Well I tend to do the same, but in reality I often can see where I want to have de-normalized design the table this way right away.

>Just as aside, I have seen a number of data designs that were fully normalized where the developer insisted that there was redundant data. A full analysis showed that what was thought to be redundant was, in fact, not redundant at all.

I'm not sure what you're trying to say here, I tend to use redundant data for debugging and recovering purpose, and of course to deal with the history problem. How do you handle history problems ?

>It is not necessary to comment everytime I talk about the logical; arguments in favor of surrogate keys. I know you don't agree, just like a lot of other people didn't agree until they found out it is the easiest way to handle things. Even I thought it was strange until I adopted it, and a good deal of problems disappeared.

I've applied it one project and did see some benefits, yes, but also some performance problems when I've had to join more tables if the only thing I wanted to do is to include a intelligent candidate key within the report. I still doubt on the subject. As i'm really hard to convince < g >, it probably takes more time and experience to change the method.

Walter,