Is it bad idea to create foreign keys on the tables in a different schemas in the same database for big applications?

I am working on the transfer a big pl/sql web-based application to the dedicated server. This application is located in one schema with 70 packages of programm code. This application was made approximately about 15 people in different times. And it was normal practice to us to create foreign keys on the reference tables in different schemas because it is really convinient and keeps database very clean, because we don't need to keep the same refernce tables in a different schemas.

But anyway my DBA (who created new instance with DB and copy my application inside of the Solaris zone) said very harsh today, "Foreign keys on the different schemas is evil and you need to destroy it!". He didn't explain his point of view.

Is it really bad idea to do that with a big applications?

Schemas are nice to isolate tables from logical subsystems. Foreign keys guarantee data integrity. These are orthogonal concepts - as obviously data integrity between subsystems is also a must have. Accounting and Shipping and possibly Central Customer Data do not live in silos where a customer can get deleted while being used in accounting.

This is how I do it on SQL Server (although, again, our definition of schema is IIRC a LITTLE different from the Oracle definition).

As such, I think the requirement of the DBA is a sign of incompetence. T

StackExchange Database Administrators Q#54772, answer score: 5