0

user_id を持つユーザー テーブルがあります。したがって、すべてのユーザー コンテンツ、ログ、詳細テーブルなどには、親ユーザー テーブルへの FK として user_id があります。これはソーシャルサイトです。したがって、ユーザーがサインアップすると、ランダムな user_id が割り当てられます。明らかに、割り当てられた ID は決して変更されないため、次のようになります。

1) user_id はとにかく変更できないため、FK 参照で「ON UPDATE CASCADE」を使用する必要はないと思いますか?

2) どのユースケースでも、user_ID FK のどこかに「ON DELETE」または「SET NULL」を設定する必要がありますか?

3) メンバーが自分のアカウントをほとんど削除した場合、私は削除フラグを設定します。しかし、ユーザーが存在しなかったようにデータベースからレコード全体を削除するように、ユーザーに強化されたプライバシーを提供しているので、2 つのケースがあります。

A) すべてのユーザーのフットプリント (ハード削除) のみを削除しますが、コンテンツは実行されたままにします。したがって、ユーザーが写真を投稿した場合、私が削除しているのはA氏が写真ID 33445を所有しているだけですが、写真は孤児として保持しています。(また、ハード削除の場合、A 氏はユーザー テーブルから削除されます)。そのため、現在、ユーザーのフットプリントを参照する約 16 のテーブルがあり、それらを NULL に設定するか、存在しないユーザーを参照するデフォルトの user_Id 999 に設定する必要があります。

B) すべてのフットプリントとすべてのコンテンツも削除します。したがって、すべて (userID と object_iD) は NULL または 999 に設定されます。ハード削除を実行している場合は、ファイル システムから写真を物理的に削除する必要があります。

これがすべて制約、トリガー、またはアプリケーション側で処理されたのかどうかさえわかりませんか? 目標は、オーバーヘッドを最小限に抑えて、できるだけシンプルかつ迅速にすることです。

プラットフォーム: MySQL、codeIgnitorPHP、専用ホスティング環境。

4

2 に答える 2

0

  1. 正しい: User_ID の変更が許可されていない場合、ON UPDATE CASCADE は無関係です。これはいい。

  2. これはあなたの側の判断です。RESTRICT を使用するのが適切なデフォルトです。ただし、User_ID が削除されたときにデータを削除する場合は、ON DELETE CASCADE が理にかなっている可能性がありますが、おそらくそうではありません。ON DELETE SET NULL は適切ではありません。

  3. 2 つの部分からなる質問 - 同様に答えてください。

    (A) 資料を削除するのは良いことです。あなたが示すように、すべての資料を削除しないのは私には良くないようです. 資料が完全に匿名 (身元不明) である可能性は低く、匿名になるものもあれば、特定できる参照を含むものもあります。したがって、(IMNSHO、もちろん) 完全に削除する必要があります。そのため、以下のオプション (B) をお勧めします。できない、またはしたくない場合は、一般的な「削除されたユーザー ID」にデータを再度関連付けることが適度に有効です。少なくとも、数十人以上のユーザーが削除されると、ジャンクが十分に存在し、ユーザーを混乱させることになります。コンテンツ。もちろん、データを匿名化するには、それ以上のことを行う必要があります。タイムスタンプなどを削除またはリセットする必要があります。孤立したデータにはアクセスできません。削除する必要があります。

    (B) これはより良い選択肢です。すべてを削除するということは、すべてを削除することを意味します。もちろん、気にしなければならないデータベースのアーカイブがあるかもしれません。情報はそれらから回復可能です。これは、おそらく ON DELETE CASCADE ルールの恩恵を受けるでしょう。おそらく、User_ID を削除済みとしてマークすることによって、最初の削除を行うことになるでしょう (「ソフト削除」)。限られた期間 (24 時間から 7 日だと思います) が経過したら、ハードな物理的な削除を行います。その時点で、ユーザーのデータは正式に削除されます。カスケードされた削除ルールを介して自動的に削除される可能性があり、テーブルの「手動スクラブ」(つまり、User_ID を取得し、その存在の証拠をすべて削除する自動化されたプロセス) によって行われる可能性があります。何かの所有者）。ただし、他の人が、現在存在しないユーザーを x-ref するコンテンツをまだ持っている可能性があること。記録全体を消去することは、実際には非常に困難です。

于 2011-01-23T01:12:41.303 に答える
0

すべての補助ユーザー情報が削除される真の「ハード削除」の場合、外部キーで ON DELETE CASCADE を使用するか、親レコードを削除する前に補助テーブルから単純に削除できます。

ユーザーレコードを削除するが補助情報を保持する「半ハード削除」の場合（私が出会ったことのないデザイン、ところで）、ON DELETE SET NULLを使用できます。ただし、外部キー列に NULL を許可するという考えは、私に意地悪を与えます (既存のユーザーからの「失われた」レコードではなく、削除されたレコードであることをどのように確認できますか?)あなたが示唆したように、この情報を含む特別なユーザーレコードを作成したいと思います。

于 2011-01-23T01:28:36.637 に答える