Разве плохая идея создавать внешние ключи для таблиц в разных схемах в одной базе данных для больших приложений?

Я работаю над переносом большого веб-приложения pl / sql на выделенный сервер. Это приложение расположено в одной схеме с 70 пакетами программного кода. Это приложение было сделано примерно около 15 человек в разное время. И для нас было обычной практикой создавать внешние ключи для ссылочных таблиц в разных схемах, потому что это действительно удобно и обеспечивает чистоту базы данных, потому что нам не нужно хранить одни и те же таблицы ссылок в разных схемах.

Но в любом случае мой администратор БД (который создал новый экземпляр с помощью DB и скопировал мое приложение в зоне Solaris) сказал сегодня очень резко: «Внешние ключи в разных схемах - это зло, и вам нужно его уничтожить!». Он не объяснил свою точку зрения.

Это действительно плохая идея сделать это с большими приложениями?

Имейте в виду - я из SQL Server и ненавижу оракула, но я думаю, что аргументация остается в силе.

Схемы хороши для изоляции таблиц от логических подсистем. Внешние ключи гарантируют целостность данных. Это ортогональные понятия, поскольку очевидно, что целостность данных между подсистемами также необходима. Учет и отгрузка и, возможно, данные Центрального клиента не находятся в бункерах, где клиент может быть удален при использовании в бухгалтерском учете.

Таким образом, я считаю, что требование DBA является признаком некомпетентности. Пожалуйста, любой может вмешаться и предоставить контраргумент - я был бы счастлив. Но это то, как я делаю это на SQL Server (хотя, опять же, наше определение схемы IIRC НЕМНОГО отличается от определения оракула).

Хотя глупо требовать уничтожения ограничений внешнего ключа без подробных рассуждений, имеет смысл держать внешние ссылки под контролем. Что если схемы, на которые вы ссылаетесь, называются по-другому на вашем новом сервере?

В Oracle вы решаете эту проблему, создавая SYNONYMS для объектов, которые находятся за пределами текущей схемы.

Если вам нужно (пробел / безопасность / что угодно) переместить любую схему в другую базу данных, вы больше не сможете обрабатывать ссылки. Это, вероятно, главная причина запроса убийства ссылок.

Единственная «плохая идея», которую я могу себе представить, сделав это, заключается в том, что вы не можете предоставить роли объектную привилегию REFERENCES (ту, которая необходима для создания ограничения, относящегося к таблице). Я должен сделать схему / пользователь схемой / пользователем.

Кроме того, я не вижу смысла вашего DBA.

Подумайте только об этом: схема владельца дочерней таблицы начинает создавать записи в своей таблице и неосознанно не позволяет пользователю схемы родительской таблицы удалять записи из родительской таблицы. Это то, что он предвидит и ценит?