Unanswered: Best practice protecting database integrity
One of the first things my first DBA mentor taught me, was to define constraints (PK, FK, check constraints, unique, ..) on as many tables and columns as possible. Business rules must first be defined on the database, before the programmers start working.
The idea behind this was to protect the integrity of the database from whatever tool that may ever be used to access the database: from the application, directly through SQL, from an MS Access connected through ODBC, ...
Nowadays, the idea is to look at the database as simply a storage for data, and define all business rules and validations in the application. All modifications must be programmed in a higher language and not directly in SQL.
What are your thoughts and experiences with these opposite points of view?
What do you consider best practice for protecting the integrity of your database?
With kind regards . . . . . SQL Server 2000/2005/2012
Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2. Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages