テーブル A に制約を作成して、テーブル B に一連のレコードが存在するかどうかを確認しようとしています。外部キーを使用できますが、問題は、テーブル B のデータが一意でないことです。
トリガーを作成せずにそのような制約を作成する方法はありますか?
編集:テーブル B の構造を変更できません。
テーブル A に制約を作成して、テーブル B に一連のレコードが存在するかどうかを確認しようとしています。外部キーを使用できますが、問題は、テーブル B のデータが一意でないことです。
トリガーを作成せずにそのような制約を作成する方法はありますか?
編集:テーブル B の構造を変更できません。
外部キーは 1:N の関係です。制約の参照先に存在できる親レコードは 1 つだけです。そのため、一意のキーを参照する外部キー制約のみを作成できます。
M:N の制約が必要なようです。これはリレーショナル モデルには適合しません。おそらく必要なのは、テーブル A の多くのレコードとテーブル B の多くのレコードをリンクする交差テーブル (AB) でしょうか? 実際、実際の要件に応じて、いくつかの異なるモデリング ソリューションが存在する場合があります。
トリガーが機能しない理由の 1 つは、トリガーがスケーリングされないためですが、主な理由は、マルチユーザー環境では機能しないためです。
1 つの手法は、マテリアライズド ビュー (コミット時の高速更新) を使用して、参照される列の一意の値を格納し、それに対してテーブルを制約することです。
トリガーを使用して整合性を確保しようとする試みは、読み取りの一貫性やロックの問題により、通常は失敗に終わります。
このような関係を強制する唯一の方法は、トリガーを使用することだと確信しています。
おっしゃるとおり、テーブル B のデータは一意ではないため、外部キーは機能しません。(外部キーは一意でないインデックスを参照できますか?も参照してください。 )
チェック制約が頭に浮かびますが、ここでは機能しません。理由は次のとおりです。
そうは言っても、テーブル B のデータが一意ではない理由は、正規化されていないためである可能性があります。おそらく中間テーブルを使用して、A と B の間の一意の関係を抽出できるかどうかを確認するために、スキーマを確認する価値があります。