Choose database level constraints where possible. Integrity 
constraints (foreign keys), check constraints (attribute domains) 
take work out of the programmers head space. It stops data from
getting scrambled.
 Any programmer who thinks about it will come to the same conclusion.
 For example, great wads of code written to check that an orderline is 
attached to an order becomes worthless if one error pops up anywhere or anytime in any application that touches the data. 
 It doesn't matter how good one programmer is if another idi0t gets 
in there and scrambles the data. Maintenance on programs goes for 
decades. And I never met a programmer that didn't think everyone 
else is an idi0t. 
 ERP applications such as Baan, PeopleSoft and SAP end up costing 
companies huge overhead to straighten out the "programmer enforced" 
constraints.
 It is one of the dirty secrets of ERP. Most of the processing that 
happens in ERP batch jobs seems to be 'fixing' the problems
brought about by bad design, old code and non-RDBMS based
architecture which fails to use database level constraints.
 The only place to use programmed constraints is where shared data
is treated differently in separate applications. In that case shared
constraints are still enforced by the database but application specific
constraints have to be handled per application.
 For testimonials just ask people who "clean" data for
loading into a data warehouse which type of database they would
rather load from....