title: using triggers to enforce data integrity - redundant?
body: <p>I have a general DB design question.</p>
  
  <p>I have a table in a database where a certain field should always have the value 0 when inserted. Changing this field to any value other than 0 involves certain actions, and these are enforced via update triggers. A record with 0 value without the proper business rules enforced is useless data.</p>
  
  <p>I am contemplating creating an instead-of trigger on insert, to enforce that you can't insert a record into this table with any value other than 0. This is not really necessary, because users can only access the database via stored procs, and the only INSERT proc currently sets this value to the default, which is 0. This would also not be a security measure since in our system only SA is a privileged user, and if a user somehow acquires the SA password, they can do whatever they want anyway.</p>
  
  <p>The only use I can think of for this, is to make sure that even in the future, no developers can accidentally allow inserting values into this field without stumbling on to the trigger, which makes is a testing tool really.</p>
  
  <p>How do DBAs approach something like this? Do you have triggers and constraints specific to testing systems, that do not deploy to production servers? Do you leave these triggers on production servers just as an extra measure of enforcing integrity?</p>