1

子テーブルと親テーブルがある場合、カスケードオプションを使用すると、親テーブルから行を削除するときに適切な子行が削除されることがわかっています。

しかし、子テーブルから最初にいくつかの行を削除する場合、これも機能しますか？親テーブルの適切な行が削除されますか？とにかく可能ですか？

編集：私は以下を含むゲームのデータベースを持っています：

  1. playerTbl（PK = PlayerID）
  2. GamesTbl（PK = GameID）
  3. GameMovesTbl（PK = MoveID、FK = GameID）

これで、ユーザーがゲームを開始するときに、ゲームに登録する必要があります（彼は自分自身、またはゲームをプレイするグループの一部になることができます）

今私がやりたいのは、あるゲームにプレーヤーが1人しかいない場合です。ユーザーがこのプレーヤーをデータベースから削除したい場合、playersTbl、適切なゲーム、およびゲームの動きからレコードが削除されます。

編集：現在、playersTblとgamesTblはお互いに見知らぬ人です。したがって、私が見る最善の解決策は、それらのテーブル間を結合する新しいテーブルを作成することです。これで、私のDBは次のようになります。

  1. PlayersTbl（PK = PlayerID）
  2. JoinTbl（FK = PlayerID、GameID）
  3. GamesTbl（PK = GameID）
  4. GameMovesTbl（PK = MoveID、FK = GameID）

したがって、カスケードオプションを使用している場合は、次のことを意味します。

  1. PlayersTblはJoinTblの親テーブルです
  2. JoinTblはGamesTblの親テーブルです
  3. GamesTblはGameMovesTblの親テーブルです

しかし、ユーザーが一部のプレーヤーを削除すると、PlayersTblとJoinTblからのみ削除されます。したがって、私の質問は、削除オプションが正しく機能するように、これらのテーブル間の最適な関係は何ですか？

4

2 に答える 2

3

いいえ、カスケード削除は、子が削除されたときに親を削除しません...また削除する必要もありません。

たとえば、Customerテーブル (親) とOrderテーブル (子) を考えてみましょう。1 つの行が削除されたからといって、その行を所有していた行も削除する必要がOrderあるわけではありません。他にも何十個もあったかもしれません...CustomerOrderCustomerOrders

削除を親から子へ、子から親へと連鎖させたい場合、これはテーブル間の 1 対 1 の関係を示しているように見えます...その時点で、それらが本当に 2 つのテーブルであるべきか、それとも1 つに結合されます。

編集：

@Elior あなたのシナリオでは、Playerは の親であり、 の親であるGame必要GameがありGameMovesます。を削除する場合Player、行を削除し、カスケード削除を有効にすると、 にGame関連付けられた行が削除され、削除された に関連付けられPlayerた削除にカスケードされます。GameMovesGame

すべてのカスケードは親から子へです...削除された子に基づいて親を削除する必要はありません。

于 2013-03-18T18:39:13.507 に答える
1

SQLトリガーを使用して参照整合性ではなく、アプリケーションでこの要件を処理するのが最善の策だと思います。アプリがストアド プロシージャを使用している場合は、そのロジックをそこに配置しても問題ありません。参照整合性は、すべての親が子レコードを持つことを保証するのではなく、孤立した子レコードを防ぐことを目的としています。

技術的には、すべての子が削除された場合に親を削除するトリガーを作成できますが、子のない親が必要な場合は、トリガーによってそれができなくなります。

アプリケーションまたはストアド プロシージャ (使用している場合) のいずれかで、そのルールをスタックの上位に配置することをお勧めします。

于 2013-03-18T18:51:25.970 に答える