And perhaps a corollary: I'm not a big fan of using lots of stored procedures and other related features (many uses of triggers and views, for instance). I'm trying to protect the data from the code, and putting code in the database compromises that.
Nigel has some good points on this above but I can't help adding my own comments. I suspect Ian's thoughts on this are colored by thoughts about SQLObject. At the moment SQLObject is an excellent (but limited) ORM. Ian is no doubt trying to find the balance between what belongs in SQLObject and what belongs in the database.
My experience is that data consistency rules belong in the database. For instance, audit tables should always be maintained by the database itself (where possible) via triggers. As Nigel said, other applications are going to use that database and you can nigh-on guarantee that they won't play by exactly the same rules unless you force them to by encoding the rules in the database itself.
Ditto constraints on the data of all types (referential, uniqueness, value).
The difficulty, as always, is making SQLObject treat database engines with different features in a consistent way, papering over the cracks.