[ThinkBeat]

This might be the case if you have one and only one application interacting with the database, and your unit tests include each and every permutation/edge case.

It is very common to have many applications, from different vendors and from different time periods interacting with a database.

It often also happens that data can be modified directly in the database, not via the application. I agree this is not best practice but in larger enterprises it happens.

Once you start implementing foreign keys in the client you are adding a lot of complexity to a problem that most mature relational database system do well enough to be trusted by a lot of traditional financial institutions.

[delinka]

These kinds of access are not proper discipline. And a lack of proper discipline is the reason to enforce constraints in production. As for "adding complexity to client apps" - how could you possibly create an app to interact with a database and not know about the structure of the database? This is beyond irresponsible. At the least, should an institution desire to allow third-party access to their database, then that access should be provided through a gateway with the intelligence to enforce constraints without relying on the database server.

[needusername]

> It often also happens that data can be modified directly in the database, not via the application.

Yup, 3rd level support "winging it" in production.

And also migration scripts.