5

テーブル A に制約を作成して、テーブル B に一連のレコードが存在するかどうかを確認しようとしています。外部キーを使用できますが、問題は、テーブル B のデータが一意でないことです。

トリガーを作成せずにそのような制約を作成する方法はありますか?

編集:テーブル B の構造を変更できません。

4

3 に答える 3

6

外部キーは 1:N の関係です。制約の参照先に存在できる親レコードは 1 つだけです。そのため、一意のキーを参照する外部キー制約のみを作成できます。

M:N の制約が必要なようです。これはリレーショナル モデルには適合しません。おそらく必要なのは、テーブル A の多くのレコードとテーブル B の多くのレコードをリンクする交差テーブル (AB) でしょうか? 実際、実際の要件に応じて、いくつかの異なるモデリング ソリューションが存在する場合があります。

トリガーが機能しない理由の 1 つは、トリガーがスケーリングされないためですが、主な理由は、マルチユーザー環境では機能しないためです。

于 2012-11-05T13:29:43.563 に答える
5

1 つの手法は、マテリアライズド ビュー (コミット時の高速更新) を使用して、参照される列の一意の値を格納し、それに対してテーブルを制約することです。

トリガーを使用して整合性を確保しようとする試みは、読み取りの一貫性やロックの問題により、通常は失敗に終わります。

于 2012-11-05T13:30:13.590 に答える
0

このような関係を強制する唯一の方法は、トリガーを使用することだと確信しています。

おっしゃるとおり、テーブル B のデータは一意ではないため、外部キーは機能しません。(外部キーは一意でないインデックスを参照できますか?も参照してください。 )

チェック制約が頭に浮かびますが、ここでは機能しません。理由は次のとおりです。

  1. 他のテーブルを参照してはなりません
  2. サブクエリを含めることはできません。

そうは言っても、テーブル B のデータが一意ではない理由は、正規化されていないためである可能性があります。おそらく中間テーブルを使用して、A と B の間の一意の関係を抽出できるかどうかを確認するために、スキーマを確認する価値があります。

于 2012-11-05T13:29:28.523 に答える