SQL 2005を使用して、車両テーブル、車両エンジン、および車両ギアテーブルを含むデータベース設計を実装しています。
各テーブルにはSQLID番号であるIDがあり、各エンジンとギアには車両IDとの関係があります。したがって、車両を作成する前に、エンジンとギアを作成する必要があります。
エンジンとギアを作成するときに、どうすれば車両ID番号を知ることができますか？エンジンとギアテーブルの外部キー制約のため、車両列はまだ作成されていませんか？
車両の作成時に、車両にリンクされたエンジンとギアの空の行を作成する自動トリガーを実装する必要がありますか？しかし、もう一度、どうすれば車両IDを知ることができますか？
どちらの場合でも、データがないテーブルに行を作成する必要はありません。たとえば、車両に匹敵しないエンジン列を用意することは問題ありません。不足しているものを見つけたら追加できます。
デザインは理解できたと思います。各車両には、1つのエンジンと1つのトランスミッションを搭載できます。ただし、車両を見つける前にトランスミッションまたはエンジンを記録することができます。
それらは実際には別個のエンティティであるため、そのように扱います。あなたは簡単にあなたが車に決してマッチしないエンジンとトランスミッションで終わるかもしれません。
もう1つの興味深い質問は、トランスミッションがエンジンに適合しているが、車両がない場合があるかどうかです。エンジンとトラムシションがボルトで固定されており、車両が見えないことがよくあります。また、一緒に販売されることもよくあります。
実際、3つのうちのいずれかが単独で存在するか、他のエンティティの1つまたは2つと一致することを想像できます。
ここでは、トリガーには役割がありません。トリガーを使用する場合は、このようなビジネスルールではなく、スキーマ構造に関するきめ細かい参照整合性ルールに制限する必要があります。必須の制約はありません-すべての外部キーはオプションです（null許容）。また、FKフィールドを設定する方法はいくつかあります。
テーブルのデザインは正しいですか？私はあなたがあなたの実体の間にどんな種類の関係を持っているのか本当に理解していません。例：車両とエンジンの間に1対多または多対1の関係を作成しようとしていますか？
1つのオプションは次のとおりです（ニーズを満たす場合）：
車両：（ID、EngineID、GearID、...）
エンジン（ID、その他のエンジンデータ）
ギア（ID、その他のギアデータ）
テーブル間に外部キー関係があるという事実は、特定の順序でデータを作成する必要があるという意味ではありません。通常、Vehicleレコードが最初に作成され、次にエンジンとギアが割り当てられることが期待されますが、そうである必要はありません。
シナリオで、車両に割り当てる前にエンジンまたはギアをデータベースに記録できる場合は、車両IDを参照するFK列でnullを許可する必要があります。車両列が作成されると、これらを車両IDにリンクできます。
または、Vehicleレコードを作成し、作成時にエンジンとギアのレコードを割り当てることもできます。
各車両に1つのエンジンと1つのギアしかありませんか？その場合、なぜそれらは異なるテーブルにあるのですか？
それらを2つのテーブルに含める必要がある場合は、次の説明に従ってINSTEAD OFINSERTトリガーを作成できます。http：//msdn.microsoft.com/en-us/library/ms175089.aspx
2つの別々のテーブルが必要な場合は、それらをビューに結合してから、更新/ビューに挿入できます...
CREATE VIEW VehicleComplete AS SELECT * FROM Vehicle INNER JOIN VehicleEngine USING(VehicleID)
UPDATE VehicleComplete SET Rego = 'ABC 123', EngineModel = '380' WHERE VehicleID = 1
個人的には、このシナリオは本当に意味がないと思います。
ギアやエンジンが存在するためには、車両が必要です。あなたのビジネスルール/ドメインモデルはそれを実際に強制するべきであり、外部キーの関係はこれが事実であることを検証するための単なる方法です。
あるいは、エンジンと車両の関係を多対多と考える方がよいかもしれません。このためには、車両とエンジンをリンクするための追加のテーブルが必要です。これは、外部キーの制約がある可能性があることを意味しますが、エンジンを多くの車にリンクできること、またはその逆も可能であることを意味します。これは、同じエンジンが多くのモデルの車で使用されている現実の世界をより現実的にモデル化したものであり、車にはさまざまなエンジンを選択できます。
この種のことは、そこにある永続性フレームワークで解決されます。典型的なO/Rマッパーのシナリオでは、必要なエンティティを（たとえば間接的に）作成するだけで、O / Rマッパーはそれらを正しい順序で保存し、FK/PKフィールドを自動的に同期します。
この種の問題と戦っている場合、すでに解決されていることに本当に時間（したがってお金）を失い、顧客の問題にその時間を費やすことはできません。ですから、あなた自身とあなたの顧客に好意を示し、少なくともそこにある永続化フレームワークのいくつかを見てください。
（免責事項：私はo / rマッパーフレームワークのリード開発者です）
しかし、もう一度、どうすれば車両IDを知ることができますか？
挿入トリガーで使用できるINSERTEDというテーブルがあります。そこに車両IDがあります。
すべての答えをありがとう。
Vehicle: (ID、その他の Vehicle データ、...) Engine (ID、VehicleID、その他のエンジン データ) Gear (ID、VehicleID、その他のギア データ)
したがって、各車両には複数のエンジンとギアを搭載できます... (はい、現実の世界ではエンジンが複数の車両に適合することはわかっていますが、それは私の目標ではありません)
SQL 2005 でデフォルトで YES に設定されている外部キー制約の強制については知りませんでした。
したがって、NOに設定して、正常に機能することを確認してください。
再度、感謝します、
オムリ。
異なる時点で実際に各エンティティを作成できない場合は、トランザクション内でそれらを作成する必要があります。各エンティティを作成するために必要な手順を明示的に示します。
トリガーソリューションは、実装が何倍も簡単ですが、重要なビジネスルールの背後に「隠れている」ため、維持するのが最も困難です。
まあ....どちらの場合でも、この種の質問は通常、悪いビジネスドメインの定義から生じるので、あなたは本当にあなたの問題の定義を見る必要があります。
結論：あなたが持っているそれぞれのトリガーは、次のプロジェクトの反復のための別の頭痛の種になるでしょう。