*snip*

>>On normalization, I think it's critical to take the initial database design to, at least, third normal form, however, I'm not opposed to break form a small bit to accomodate tool and performance issues BUT (big but because jason got back!) only after reaching third normal form and documenting reasons why the regression was taken.
>>
>>Calculated fields are evil! :)
>
>I have the one type of case where I have a sort-of calculated field, and that's the tables which are used to build treeviews. I've had a hierarchical organizational structure (divisions, subdivisions, subsubdivisions etc), which was loaded from an external text file into a table, and then it was recursively scanned to build the tree. I added one field which was the treeview key. Its sole purpose was to put the records into the order they needed to be to populate the treeview sequentially. The process got sped up by a factor of 30 (the slow part ran only when a new text file arrived, not each time a treeview was drawn).
>
>Don't know if this counts as a calculated field, because it's not calculated within the record, but rather from the position of the record related to other records. It still needed to be repopulated each time the table changed, so in that sense it was a calculated field.
>
>I've used this less than ten times in the last three years - and I still keep that one highlighted in my mind, because it's such a damn exception that needs special handling. I wish I had a simpler and more elegant solution.

I view this more of a system field rather than a calculated field. Similar to a transactional flag such as SentDate or ArchiveDate. The type of calculated field I'm thinking about is something like InvoiceTotal or StudentCount. Storing the invoice total sounds like a good idea because tax and shipping charges can change after invoicing and throw off totals....of course, one could just store the then current tax rate. :) Besides, even if it is an evil calculated field, the performance gains sound too good to not use it.

Calculated fields definitely have their place, especially in data warehousing and "snapshot in time" systems. I call them evil but they are just sometimes used in ways that weaking the integrity of a system.