>I probably would have agreed 100% a year ago. But now, with the discussion of n-Tier development, I think you can divorce (or view separately) the two.
>
>For example, the database arguable exists outside of any application that might access it. (If we start thinking enterprise-wide applications.) So if your database depends in anyway on your application to maintain integrity, what happens when another division writes and application that accesses pieces of the database?
>
>>I do not know if you can totally divorce the 2. {snip} Conversely, sound application design is essential to data integrity as well.

I guess the assumption that all data integrity checks are contained in the stored procedures of the database, default values, triggers, etc. I (and perhaps many) do not always think in these terms. While I do have some stored procedures (e.g., RI, PK generator which is called by code placed in the default value of the PK field), I do not always follow strict DB modeling. Now if I were designing a DB where the front-end were unknow or variable, then I would dang sure build all the integrity constraints into the DB.