99% agree with Joe here.  I can always tell when a database has been coded by an application developer(s) they are universally terrible.  Keep them separate and design the database FIRST.  Treat the application as the presentation layer for data that it is, rather than treating the database as a storage mechanism for the application.

I also agree that it's a problem that the app and DB don't share the data dictionary, but as long as applications are built using hierarchical data constructs (OO) it will always be that way.  The real problem is that most of the time when the "impedance mismatch" is invoked, the database is assumed to be at fault when it is actually the programming languages that use the demonstrably inferior data constructs.

Sorry Andy, but I can't resist...  Here's where I disagree with Joe.  Identities are fine for some things.  Obviously they don't work so well when you need to ensure gapless sequences etc...  And I just laugh (cry) when I see a database that has an identity on every stinking table.  But when you need a system generated surrogate key, why not?  Nothing else will perform as well or be so convienient (at least in the SQL Server world).  I do wish MS would implement sequences though...  There is nothing "non-relational" about identities, proprietary and non portable...yes, but since the RM does not proscribe them and does not prescribe how surrogate keys must be generated saying they are "non-relational" is hyperbole.

As for using surrogate keys for code tables, I generally don't like the idea.  Sure it allows you to redefine the code without making a bunch of updates, but I don't view that as being a real positive in most cases.  As for the negative, it forces you to do a lot of otherwise unnecessary joins, hurting overall performance. 

100% agree that statuses are NOT entities per se, they are attributes whose values can and should be constrained by a FK but that doesn't make them entities.  Thinking of codes as entities leads one to use MUCK tables.

The problem is that application development and database design require two totally different skillsets and mindsets.  I've never met anyone who could effectively do both.  I've met a bunch of people who THINK they can do both, but reality is very different. 

"I've never met anyone who could effectively do both."

Well, I'm going to be immodest here and say that I do both sides of the coin fairly well, and I expect that the developers who work with/for me do as well. I need people who learn the tools needed to do the job, whether they're front end, back end, scripting, OO, whatever. I resent like heck the time and money wasted "mapping" an OO hierarchy to a relational db structure. Makes no sense to me.

DRI Transition Constraints (http://www.dbazine.com/ofinterest/oi-articles/celko35) - Are the way to go!

I've used this concept for years and everyone gets it from BAs to BI developers. It's beauty for me is that systems never stand still, and as sure as eggs are eggs, someone going to change it and then all you need is a another row in a table (i.e. no 'coding'). They are also create for populating drop down lists for valid transitions.

Apart from creation dates, I tend to use default constraints for bit flags, like this:

Active bit NOT NULL DEFAULT 1

When used in this way, a new record begins life as an active record. Later, when the record is ready to be deleted by the audit process, the flag gets set to 0.