データベースに2つのテーブルがあります。 表1 '受注明細'および表2 '受注'です。 'オーダー'は、0以上の 'オーダーID'を持つことができます。 主キーをリンクするFK制約を定義しました：OrderIdとOrderItemIdとDeleteRuleを 'Cascade'に設定しました。 これにより、Orderを削除するとすべてのOrderItemが削除されます。SQL Serverで1対1の関係を強制
私が避ける必要があるのは、空の注文です。注文がAT LEAST OrderItemであることを確認する必要があります。それ以外の場合は、最後にリンクされたOrderItemが削除されると自動的に自動的に削除されます。私はもちろん、私のアプリでこれをチェックすることができますが、理想的にはDBはこれに対処することができます。
私はORMとしてMS SQL Server 2008とEntity Frameworkを使用しています。
ありがとうございます！
このような関係は、通常のリレーショナルルールを使用して実行可能ではありません。結局のところ、注文をどのように追加しますか？注文なしで注文アイテムを追加することはできませんが、注文アイテムを持たない注文はできません。あなたは鶏卵のシナリオに入ります。
あなたの唯一の真の解決策は、それが最後の項目だ場合は、対応する順序を削除OrderItemテーブルの上に削除トリガーを作成することです。
この双方向関係は、dbスキーマでは実行できません。おそらくビジネスロジックにこれを強制する必要があります。
私はこれを行うための制約に基づく方法に気づいていません。 OrderItemテーブルからの削除でトリガを成功させると、「子なし」のOrderレコードが削除され、削除される可能性があります。これはヘビーウェイトの「海洋」アプローチである可能性があります。 @crcvensが推奨するように、ビジネスロジックのシナリオです。
ビジネスロジックでこれを行うのがなぜ良いでしょうか？ OrderItemが削除されるたびに、Orderに他のOrderItemが残っているかどうかを確認する必要があります。削除トリガーがDeleteでのみ発生すると仮定します。 – santiagoIT
@santiagoIT本当ですが、削除トリガーでは削除された「OrderItem」レコードのOrderIDを特定できない可能性があります。したがって、すべての「Order」レコードをスキャンして残りの子があるかどうかを確認する必要があります私はトリガのクエリからそのような種類の情報を取得する方法はわかりません）。このチェックをビジネスロジックで実行すると、影響を受けたOrderIDを保持し、それらの「Orders」のみを削除対象として評価することができます。 –
@santiagoIT私の前のコメントを無視しても構いません.- @Adam Robinsonは、この点でトリガーがどのように機能するか説明しました。 –
残りの注文アイテムがあるかどうかを確認して注文をアーカイブする場合は、UPDATE TRIGGERをご検討ください。
これは、表の行の変更ごとに発生します。そのため、ロジックとそれに伴うパフォーマンスには注意が必要です。
削除トリガーはDeleteの場合にのみ起動しますか？または@Dave Andersonが以下に示唆するように、すべての変更で発生しますか？ – santiagoIT
@santiagoIT：挿入、更新、および削除のためにトリガするトリガを定義できます。 –
トリガーを削除すると、削除されたレコードのデータを簡単に認識できますか？たとえば、2年以上経過したすべてのOrderItemsを削除した場合、トリガーは対応するOrderIDを識別できますか、または0人の子供のすべてのOrdersをチェックする必要がありますか？ –