2012-04-27 27 views
3

私は2つのテーブル、1つの 'マスター'テーブルと1つの '子'テーブルを持っています。 各テーブルには、ProductNoという名前のフィールドがあり、PRIMARY KEYおよびUNIQUEとして定義されています。 テーブル 'child'に 'ProductNo'フィールドを定義し、テーブル 'master'に同じフィールドをPRIMARY + UNIQUEとして定義することはできますか?2つのテーブルの主キー

master: 
ID | ProductNo 

child: 
ID | MasterID (FK on master.ID) | ProductNo 

Relation >> 1 (master) : n (child) 


example data: 
master: 
1 | 1234 
2 | 4567 

child: 
100 | 1 | 3333 
101 | 1 | 4444 
102 | 2 | 5555 
103 | 1 | 1234 <----- NOT ALLOWED! PRODUCT NO ALREADY EXISTING IN TABLE `MASTER` 
104 | 2 | 1234 <----- NOT ALLOWED! PRODUCT NO ALREADY EXISTING IN TABLE `MASTER` 

テーブル 'master'に 'ProductNo'が既に存在する場合は、 'child'テーブルの挿入/更新をチェックする必要があります。

どうすれば定義できますか? また、このためのトリガーを作成する必要がありますか?

TIAマット

+3

プライマリ+ユニークの意味は?主キーはデフォルトで一意です。2つの違いはプライマリキーだけがヌル値を受け入れないことです –

+0

'child'テーブルの行は、他のIDが一致するかどうかにかかわらず' master'の行と同じ 'ProductNo'を持つことができません?いくつかのサンプルデータと期待される結果(許可または拒否の更新)が役立ちます。 – onedaywhen

+0

既に 'master'テーブルにある' child'テーブルにProductNoを持たせることはできません。 – frgtv10

答えて

4

いいえ、テーブル間に複合PKsはありません。

データの一貫性のために、Idが同じ場合は、FKを子からマスターに追加する必要があります。あなたの問題を解決するために

、このようなチェックとトリガー:

実際に最高のアイデアと呼ばれる1つのテーブルのみを持つことです。

if exists (select 1 from master where prodcutId=new_productId) 

EDIT良いでしょうIDと、それ自身との関係を持つmasterIDフィールドを持つ製品。あなたが今日持っている方法私はかなりあなたが重複データをたくさん持っていることをかなり確信して、あなたは階層の2つのレベルで立ち往生しています。

+0

メインスレッドのサンプルデータを更新しました。これはまだ最良の方法だと思います。右? – frgtv10

+0

はい、私の編集 – Diego

+0

を見てみましょうトリガを使用して完璧な動作します。私は1つのテーブルを使用することはできませんので、 'マスター'多くのフィールドを持っているので、テーブル '子ども ' – frgtv10

2

(オリジナル答)あなたも、子の主キーへの外部キーポイント場合は、マスターから子への外部キーを宣言することができます。これは1対1の関係になり、珍しいことではありません。子の行は、すでに挿入されているマスターの一致する行なしでは存在できませんが、子の行が一致していないマスターの行が存在する可能性があります。あなたの挿入物は、マスターと子供の順序で起こる必要があります。

(あなたの場合、あなたの場合は、テーブルのプライマリキーではないはずですが、別のプライマリ/外部キーがあります問題の列は2つのテーブルで一意である必要があります。これで、サンプルデータの一部を編集したことが明らかになりました。この場合、両方のテーブルでトリガを使用して、他のテーブルに存在を確認し、ProductNoがすでに存在する場合には挿入/更新を防ぐのが最善です。

+0

私は1:nの関係を持っています。つまり、私は 'ProductNo'にfkを使用できません。 – frgtv10

+0

Product Noが一意の場合はどうすればよいですか? –

+0

私のサンプルデータを見てください。メインスレッド – frgtv10

0

子テーブルにProductNoという名前の列を追加し、親テーブルに外部キー参照を追加できます。

1

@DavidMと同じように、それは実行できますが、モデリングの問題があるようです。まず、自然な主キーProductNoがある場合、なぜ代理人IDを定義しますか?もう1つのことは、これらの2つのテーブルを1つのテーブルに結合することです(1対1の大部分のケースでは意味があります)。

+0

これは真実かもしれない、ええ。しかし、テーブル「マスター」には約40のフィールドがあり、テーブルの「子供」には5フィールドしかありません。それでなぜ我々は2つのテーブルを使用しているのですか? – frgtv10

+0

@ frgtv10では、モデリングの選択肢はソリューション固有のもので、もちろん理由はあります。私の指摘は、この選択によってもたらされる利点とトレードオフを考慮することです.1対1が単一の表としてモデル化されていれば、この問題は問題ではありません。 –

1

本当に2つのテーブルが必要ですか? プロダクトIDとparentIDの両方を1つだけ保持してください。 次にproductIDはプライマリキーと自動インクリメントになりますが、null以外のもの(同じテーブルへのf.keyed)を持つものはすべて子アイテムになります。

関連する問題