6

I have the following database schema:

members_company1(id, name, ...);
members_company2(id, name, ...);
profiles(memberid, membertypeid, ...);
membertypes(id, name, ...)
[ 
       { id : 1, name : 'company1', ... }, 
       { id : 2, name : 'company2', ... }
];

So each profile belongs to a certain member either from company1 or company2 depending on membertypeid value

members_company1     —————————      members_company2     
————————————————                    ————————————————
id      ——————————&gt; memberid <———————————         id
name               membertypeid                 name
                       /|\
                        |  
                        |  
      profiles          |  
      ——————————        |  
      memberid  ————————+  
      membertypeid

I am wondering if it's possible to create a foreign key in profiles table for referential integrity based on memberid and membertypeid pair to reference either members_company1 or members_company2 table records?

4

5 に答える 5

4

ドキュメントに記載されているように、外部キーは1つのテーブルのみを参照できます（強調鉱山）：

外部キー (FK) は、 2 つのテーブルのデータ間のリンクを確立して適用するために使用される列または列の組み合わせです。

ただし、物事のクリーンアップを開始したい場合はmembers、@KevinCrowell が提案したようにテーブルを作成し、2 つのmembers_companyテーブルからデータを入力してビューに置き換えることができます。ビューでトリガーを使用INSTEAD OFして、更新を新しいテーブルに「リダイレクト」できます。これはまだ作業が必要ですが、既存のアプリケーションを壊さずにデータ モデルを修正する方法の 1 つです (もちろん、あなたの状況で実行可能であれば)。

于 2013-04-11T14:33:18.220 に答える
1

さあ、テーブルを作成できますが、members_company1 も members_company2 も変更できませんか?

members テーブルを作成するという考えでは、新しいレコードが members_company テーブルに挿入されるときに、さらに多くのアクションが必要になります。
members_company1 と members_company2 でトリガーを作成できますが、これは変更ではありませんか?

あなたができることに対する制約は何ですか？

members_company1 と members_company2 への選択に関する互換性のみが必要な場合は、実際のメンバー テーブルを作成し、members_company1 と members_company2 のビューを作成します。
基本的な選択は、それが反対側のビューまたはテーブルであることを認識しません。

CREATE VIEW dbo.members_company1
AS
SELECT id, name 
FROM members
where companyID = 1

代わりに挿入、更新、および削除を処理することもできます

INSTEAD OF INSERT トリガー

于 2013-04-10T21:48:48.637 に答える
1

テーブル構造を変更できないという事実の下での操作：

オプション1

参照整合性はあなたにとってどのくらい重要ですか? これらのテーブル間で内部結合のみを行っていますか? あまり気にする必要がないなら、気にしないでください。

オプション 2

わかりました、おそらくこれについて何かをしなければなりません。おそらく、内部結合しかないのに、メンバー テーブル内の何にも関連しないプロファイル内のデータを処理する必要があります。それを一掃するために、1 日または 1 週間に 1 回実行されるジョブを作成できますか?

オプション 3

ええ、それもうまくいかないかもしれません。メンバー テーブルへの参照をチェックするトリガーをプロファイル テーブルに作成できます。これは理想とはほど遠いですが、瞬時のチェックが保証されます。

私の意見

オプション 2 を使用します。明らかに、理想的とは言えないスキーマを扱っています。なぜこれを必要以上に悪化させるのですか。悪いデータを 1 週間放置します。毎週末テーブルをきれいにします。

于 2013-04-10T21:06:35.110 に答える
0

外部キーは 2 つのテーブルを参照できません。members_company1とmembers_company2テーブルをマージして設計を修正したくない場合、最善の方法は次のとおりです。

member_company1_idandという名前の 2 つの列member_company2_idをテーブルに追加profilesし、2 つのテーブルに 2 つの外部キーを作成して、 を許可しnullsます。次に、制約を追加してnull、常に列の 1 つがそうであり、もう 1 つがそうでないことを確認できます。

于 2013-04-10T21:15:40.627 に答える