I definitely fall on the "Constraint Yourself" side of the argument. I've been designing databases for 15 years now and am always amazed at the number of people in this business who profess to use Relational Databases but are vehemently opposed to constraints. Constraints are an integral part of what a RDBMS is---and that includes column constraints, table constraints, null constraints, domain constraints, PK constraints, unique constraints, FK constraints AND TRIGGERS. Triggers are part of how an RDBMS enforces data integrity; they are not there to perform business processes.

Support for stored procedures and triggers that implement business process are features that DBMS vendors include in their products to sell their product, but they are not part of the features and requirements that define what an RDBMS is.

Using an RDBMS without including the appropriate constraints is like a town building a firestation but not buying any trucks or hiring any firefighters and then claiming to have a Fire Department. All you've got is a shell with potential that is not being used and cannot possibly be expected to perform the function it was designed for.

We had "dumb databases" in the 60's. That is one of the main reasons that Codd theorized and defined the RDBMS.