Re^7: (OT) Couple of Data Model Design Considerations

[jZed]

This entire subthread seems like a good example of something that sheds more heat than light. Ok, so maybe tinita's original posting needed a bit of clarifification, that doesn't mean it was wrong. herveus's use of phrases like "blithely" and "somone who ... does not have enough depth" are , IMNSHO, uncalled for, as is the heavy-handed lecturing against a position which, by my reading, tinita never took in the first place. Which doesn't negate the fact that I agree with much of what herveus says about normalization. Lighten up folks!

[aquarium]

it's all good...as long as no-one's taking it too personally or getting a heart attack.
as for the question for normalization vs de-normalization: de-normalization is a conscious attempt to reduce the number of tables etc by working from a normalized model. i.e. it's not the same as not bothering to normalize in the first place, which is un-normalized/adhoc/dangerous design. de-normalization introduces problems of its own, which will need to be coded around. the most warranted case for de-normalization is calculated fields, where a run-time live calculation (say for order total) would cause too much of a performance hit. the drawback is that any part of the order or order-lines is modified, one must ensure the order total is re-calculated.