Re: SQL and defining data structures

<nathan>
You may expect to add instead of triggers in the future, but I wouldn't. I
would not base decisions today on a design philosophy that a database which
is already normalized to 3rd normal form today, would need to be normalized
differently in the future.
</nathan>

Instead triggers are sometimes, but rarely needed and IMHO only acceptable for a interim time of restructuring a database. The very drawback of triggers and especially instead triggers is, that you loose all benefit of set based processing.
Im with you, that in a well normalized database the most common change would be adding fields, but this depends on business needs too (for example consolidation of two databases after merging companies together). Never the less you will win flexibility with a complete view layer and even adding a field will be easier with a view layer (I know you could decouple by renaming the table, adding a view with the former tablename, but it's more work to do during a critical operation). I don't see valid arguments against a view layer in your responses or did I overlook something?

Dieter