別のスキーマのテーブルの列を参照して、テーブルの1つに外部キーを作成しようとしました。
そんな感じ:
ALTER TABLE my_schema.my_table ADD (
CONSTRAINT my_fk
FOREIGN KEY (my_id)
REFERENCES other_schema.other_table(other_id)
)
必要な助成金があったので、これはうまくいきました。
今、私は別のスキーマのテーブルを参照しない理由があるのか、何か注意する必要があるのだろうか?
これを行うのに問題はありません。スキーマは、テーブル間の外部キー関係を確立する際に実際には影響を与えません。適切な人が、使用するスキーマに必要な権限を持っていることを確認してください。
これは、独自のスキーマ内のテーブルを参照する外部キーとして正確に機能します。
通常の外部キーと同様に、親キーが更新された場合、または親テーブルからエントリを削除した場合は、my_id
のインデックスを作成することを忘れないでくださいとにかく)。
さまざまな人がさまざまなスキーマに対する権限を持っている組織にいる場合、他のスキーマに制約を無効にする、またはドロップして再作成する機能を与えることをお勧めします。
たとえば、(非常に奇妙な)サポートの問題を処理するために、テーブルを削除または切り捨ててからリロードする必要があります。真夜中に電話をかけたくない限り、制約を一時的に削除する機能を提供することをお勧めします。 (外部制約のいずれかが無効化または削除されるかどうかを知るために、独自のアラートを設定することも推奨します)組織/スキーマの境界を越えているときは、他の人とうまくやりたいと思うでしょう。 Vincentが言及したインデックスは、その別の部分です。
私が遭遇した唯一のことは、許可が他のスキーマに存在することを確認することでした。通常のもの-何らかの理由でそれらの許可が消えた場合、あなたはそれについて聞くでしょう。
これが問題を引き起こす可能性がある1つの理由は、正しい順序で物事を削除するように注意する必要があることです。これは、テーブルに孤児を入れないことがどれだけ重要かによって、良い場合も悪い場合もあります。