0

ユーザー（User）のテーブルがあり、どのユーザーが他のユーザーを参照したかを追跡するために新しいテーブルを作成する必要があります。したがって、基本的に、同じテーブルの行間に多対多の関係を作成しています。

そのため、UserId列とUserReferredId列を使用してテーブルUserReferralsを作成しようとしています。両方の列を複合主キーにしました。また、両方の列はUser.UserIDにリンクする外部キーです。

ユーザーを削除すると関係も削除されるはずなので、両方の外部キーをカスケード削除に設定しました。ユーザーが削除されると、UserReferralsの関連する行もすべて削除されます。

しかし、これは私にメッセージを与えます：

'User' table saved successfully 'UserReferrals' table Unable to create relationship 'FK_UserReferrals_User'. Introducing FOREIGN KEY constraint 'FK_UserReferrals_User' on table 'UserReferrals' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Could not create constraint. See previous errors.

このエラーは発生しません。カスケード削除は、外部​​キーを持つ行のみを削除しますよね？では、どのようにして「サイクリングカスケードパス」を引き起こすことができるのでしょうか。

ヒントをありがとう。

4

3 に答える 3

1

テーブル（A）にFKがあり、テーブル（B）が（A）とも関係がある場合、または同じテーブル内のPKを参照するFKがある場合、それが循環するシナリオを導入できます。これが論理的に不可能な場合もありますが、純粋な理論では、SQLエンジンの観点からは可能です。

これは避けられません。通常、これらはSPで処理されます（EFではdeleteメソッドにマップできます）。

于 2011-01-12T01:44:01.577 に答える
0

カスケード削除を許可する場合、他のユーザーのUserReferredIdフィールドにUserIdが表示されているユーザーを削除すると、それらのユーザーも削除されます。関連付けられているユーザーが削除された場合、UserReferredIdの値をnullに設定することが必要だと思います。

削除コマンドでのテーブルトリガーから、削除にストアドプロシージャを使用する方法まで、いくつかのアプローチがあります。トリガーを無視することは邪悪な議論であり、次のようなものを作成することができます。

トリガーclearUserReferredIdOnUserDeleteを作成し、ユーザーを更新して削除した後、UserReferredId = nullを設定します。ここで、UserReferredId in（削除されたユーザーIDを選択）

これはテストされていませんが、近いはずです。

P

于 2011-01-12T01:49:21.863 に答える
0

これを考えた後、問題は複数のカスケードパスに関連している可能性があるので、サイクリックカスケードパスにはあまり関連していないと思い始めています。

結合テーブルの2つのUserIDは常に異なりますが、同じになることを妨げるものは何もありません。両方が同じユーザーを参照していて、そのユーザーが削除された場合、結合テーブルへの複数のカスケードパスが存在します。

于 2011-01-12T04:27:37.460 に答える