2009-04-15 7 views
0

1:mの関係を持つデータベーステーブルにレコードを挿入するときは、関連するテーブルが更新されていることを確認するのはベストプラクティスではありません)新しいレコードで?関連するテーブルのうちの1つだけが更新されても影響はありますか?1:m関係のテーブル部分にデータを挿入する質問

また、関係のm側の表を更新すると(たとえば、1台の車に複数の車輪を持たせても、1台の車輪は1台の車にしか所属できない車と車輪の関係)明示的なパラメータとしての外部キー?例えば。他の関連するテーブルに1,2,3,4,5のPKシステムがあり、ユニークなやり方で登場する場合は、ストアドプロシージャを使用して外部キー値を値として挿入するだけですか?

EDIT:これは非常にn00bishと聞こえますが、残念ながら私は学習とデータベース設計とSql Serverの学習は、特に自己練習(正式訓練なし)からしかありません。

答えて

1

のはあなたの例を使用してみましょう。..

car: 
    car_id 
    name 

wheel: 
    wheel_id 
    car_id 

ことはあなたの最初の質問は、あなたがwheelテーブルにレコードを挿入するときに、対応する行がcarテーブルであることを確認すべきであるかどうかを尋ねるされている場合は、はい!実際に、RDBMSが外部キーで正しく設定されている場合は、carに親行を持たないwheelテーブルに行を挿入することはできません。

これはあなたの2番目の質問にも対処できると思います。もしそうでなければ、あなたは精緻化できますか?

+0

こんにちは、私の2番目の質問にもあてはまります! :)私は大規模なデータベーススキーマでは、関係するテーブルを持つことができますが、すべてのテーブルを埋めるための詳細を提供していない疑問に思っていること。たとえば、製品はコメント(関係)を持つことができますが、製品はコメントなしで追加できます(Amazonなど)。 – dotnetdev

+0

コメントにより、ユーザーレビューのような商品を言及していることがありますか?そうであれば、子供がいない親レコードを持つことは確かに可能です(多くの場合、適切です)。 –

0

1対多リレーションシップがある場合、最初にレコードを親テーブルに挿入する必要があります。親テーブルへの挿入時に、子テーブルにも挿入する必要はありません。これはデザインに完全に依存しており、インライフレコードが挿入された時点で利用可能な情報はあります。例えば、顧客と注文は1対多の関係を持っています。しかし、顧客が実際に何かを購入する前にクソマーが追加され、注文がないこともあります。または、新しい顧客が何かを購入しようとしている可能性があり、顧客情報とその注文の両方を保存する必要があります。あなたは、datanbase構造を設定する時に、プロメトリキー/外部キーの関係を設定する必要があります。これにより、関連する顧客がいなくても決して注文することができなくなります。 Orderテーブルでは、Customerテーブルからidフィールドの列を追加します。レコードを挿入すると、この値は他の情報と同様に挿入の一部になります。

親テーブルまたは子テーブルを更新する場合は、PK.FK関係のあるフィールドを変更しない限り、別のテーブルを更新する必要はありません。この値を決して変更しないのが最善です(プライマリキーはほとんどの場合、チャネリングする必要はありません)。プライマリキーの名前などを使用している場合は、デザインを考え直す必要があります。

関連する問題