1

ベンダー

(PK) - ID
名

台

(PK) - Id
VendorId - fk - Vendor が削除された場合はカスケード削除)
名前

アイテム

(PK) - Id
VendorId - (fk - ベンダーが削除された場合はカスケード削除)
名前
価格

利用できないアイテム

(PK) - ItemId - (fk -アイテムが削除された場合のカスケード削除)
(PK) - StandId - (fk - スタンドが削除された場合のカスケード削除)

上記のデータベースは、競技場を表しています。

  • 複数のベンダーが存在します (ボブのピザ、トムのタコス...)
  • ベンダーごとに複数のスタンドが存在します (ボブズ ピザ コンコース A、ボブズ ピザ コンコース B...)
  • 特定のベンダーのすべてのスタンドが同じアイテムを同じ価格で提供するため、アイテムはベンダーによって構成されます。
  • スタンドは特定のアイテムを使い果たす可能性があるため、UnavailableItems テーブルには、特定のスタンドで利用できなくなった各アイテムのレコードがあります (ItemId と StandId の複合主キーを使用)。

    問題：

    リストされている最後の外部キー (FK_UnavailableItem_StandId_Stand_Id) を削除ルール: Cascaded で追加するまで、すべて問題なく作成できます。

    SQL Compact 3.5 (VS 2010 サーバー エクスプローラーを使用) は、次のエラーを報告します: 参照関係により、許可されていない循環参照が発生します。

    UnavailableItem テーブルにレコードがあり、その Vendor が削除された場合、削除が 2 回試行されることを理解しています。

  • 参照アイテムが削除されたため、1 回。
  • 参照されているスタンドが削除されたため、1 回。

    しかし、これは私には周期的ではないようです。カスケード削除は 2 つのパス (削除されたスタンドと削除されたアイテム) に分岐し、どちらも削除される同じレコードで終了します... しかし、そこで終了します。その後、カスケード削除の無限ループはありません。何か不足していますか、それとも使用しているツールの制限ですか?

    あなたが提供できる助けをありがとう！

    • 4

    2 に答える 2

    2

    ツールの制限により、2 つのブランチを介して削除をカスケードすることはできません。しかし、カスケード削除は、とにかく、貧しい無実のデータベースに対して行うのは一般的に悪いことです。一番下のテーブルから削除して、上に移動します。そうすれば、一番下に 100000000000 レコードがある場合、それらをバッチで実行してパフォーマンスを向上させることができます。カスケード削除は、パフォーマンスの問題を引き起こす可能性があります。

    于 2010-09-17T21:07:02.100 に答える
    1

    SSCE が 2 つのパスに沿ったカスケード削除を許可しないと仮定すると、UnavailableItem.StandId のカスケード削除を削除できます。

    少なくとも、ベンダーまたはアイテムが削除された場合でもカスケードします。

    また、UnavailableItem に削除されたスタンドの行がまだ含まれている場合、少なくとも UnavailableItem をスタンドと結合するとき、補充オーダーを作成するときにそれらを除外することができます...

    于 2010-09-21T04:19:51.370 に答える