Is this a troll to get mentioned in the "To Laugh Or To Cry" section of Database Debunkings?
Foreign key constraints, like all constraints are there to enforce integrity and to make relationships explicit (like a specification with teeth).
If every application accessing the database has to know about and enforce integrity constraints you are multiplying the work -- remember the DRY principle. Moving constraints out of the database seems like a good idea, if you have never worked with a system that has multiple applications accessing the database, written by different teams in different languages, over time. You are imagining a single application with a "database access layer," but even then you are duplicating functionality in application code that the RDBMS gives you.
If your production data is not important then go ahead and turn those constraints off. For real businesses the integrity and consistency of the business data is more important than application code.
Foreign key constraints, like all constraints are there to enforce integrity and to make relationships explicit (like a specification with teeth).
If every application accessing the database has to know about and enforce integrity constraints you are multiplying the work -- remember the DRY principle. Moving constraints out of the database seems like a good idea, if you have never worked with a system that has multiple applications accessing the database, written by different teams in different languages, over time. You are imagining a single application with a "database access layer," but even then you are duplicating functionality in application code that the RDBMS gives you.
If your production data is not important then go ahead and turn those constraints off. For real businesses the integrity and consistency of the business data is more important than application code.