大きなアプリケーションのために、同じデータベースの異なるスキーマのテーブルに外部キーを作成するのは悪い考えですか？
私は大きなpl/sql webベースのアプリケーションを専用サーバーに転送する作業をしています。このアプリケーションは、70のプログラムコードパッケージを持つ1つのスキーマにあります。この申請は、異なる時期に約15人で行われました。異なるスキーマの参照テーブルに外部キーを作成するのは通常の慣例でした。異なるスキーマの同じ参照テーブルを保持する必要がないため、データベースを非常に便利でクリーンに保つためです。
しかしとにかく、私のデータベース管理者（DBで新しいインスタンスを作成し、アプリケーションをSolarisゾーン内にコピーした）は今日、「さまざまなスキーマの外部キーは悪質であり、破棄する必要がある！」彼は自分の見解を説明しなかった。
大きなアプリケーションでそれを行うのは本当に悪い考えですか？
Bearwith me-私はSQL Server出身でOracleが嫌いですが、議論はまだ残っていると思います。
スキーマは、テーブルを論理サブシステムから分離するのに適しています。外部キーはデータの整合性を保証します。これらは直交する概念です。サブシステム間のデータの整合性も当然必要です。会計と配送、そしておそらく中央顧客データは、顧客が会計に使用されている間に削除される可能性があるサイロには存在しません。
そのため、DBAの要件は無能の兆候だと思います。誰かが介入して反論を提供できるようにしてください-私は幸せです。しかし、これは私がSQL Serverで行う方法です（ただし、スキーマの定義はIIRCであり、Oracleの定義とは少し異なります）。
詳細な理由なしに外部キー制約の破棄を要求するのは愚かですが、外部参照を制御下に置くことは理にかなっています。参照しているスキーマの名前が新しいサーバーで異なる場合はどうなりますか？
Oracleでは、現在のスキーマの外部にあるオブジェクトに対してSYNONYMSを作成することにより、この問題を解決します。
スキーマを別のデータベースに移動する必要がある場合（スペース/セキュリティ/その他）は、参照を処理できなくなります。これがおそらく、参照の削除を要求する主な理由です。
これを行うことから想像できる唯一の「悪い考え」は、REFERENCESオブジェクト特権（テーブルを参照する制約を作成するために必要な特権）をロールに付与できないことです。 schema/userごとにschema/userを実行する必要があります。
それ以外に、DBAの要点はわかりません。
考えてみてください。子テーブルの所有者スキーマは、そのテーブルにレコードを作成し始め、無意識のうちに親テーブルスキーマのユーザーが親テーブルからレコードを削除できなくなります。それはそれが予期して高く評価するものですか？