If I understand Brian's post he's not entirely out in left field, although I think running with *no* data integrity is a huge mistake.
I think what he's saying is designing an application so that it's impossible for bad data to get to the SQL engine is the best solution.
And I half-way agree with him--but I'm a belt, suspenders and jumpsuit kind of guy myself... 🙂
I run a one man shop and it's very nice to be developer, DBA, and systems analyst all rolled into one. Of course most folks don't understand the impact of that "tiny" new feature, but hey, that's life...
At any rate I think letting the SQL engine handle basic integrity tasks is a much better solution. Things like referential integrity, bounds checking, unique constraints are no brainers for the DB, no question. Auditing's another DB level task that as a developer I'm *happy* to let the DB handle. The coding overhead is minimal and the results damn near foolproof.
Howsomever:
Some things are better handled by the application. There's no need to bother the DB with things like checking to see if input to a numeric field is actually numeric! Using combo boxes to make it impossible to choose an impossible field value is another way to leverage local processing power.
The database is busy enough, no need to make it work harder than it must. Not to mention eliminating excessive talk on the wire, which is a good thing too.
If you're a DBA you tend to want *everything* in the back end. Not a good idea. Your server is a limited resource being devoured by a swarm of users. Those users have abundent local resources. The best designs take advantage of those local resources.
It's all about balance. Let the DB do what it's good at and the application do what it's good at.