ユーザデータのFKにはどのような制約がありますか？

Question

user_idを持つuserテーブルがあります。したがって、すべてのユーザーのコンテンツ、ログ、詳細テーブルなどは、親Userテーブルに対するFKとしてのuser_idを持っています。これはソーシャルサイトです。したがって、ユーザーがサインアップすると、ランダムなuser_idが割り当てられます。

1）user_idは決して変更できないので、私はFKリファレンスで "ON UPDATE CASCADE"を使う必要はないと思いますか？

2）usecaseのuser_ID FKのどこにでも "ON DELETE"または "SET NULL"を設定する必要がありますか？

3）メンバーが自分のアカウントを大部分削除すると、削除フラグが設定されます。しかし、私は2つのケースがあるので、私は2つのケースがあるので、データベースからレコードをすべて削除するようにユーザーにプライバシーを強化しています。

A）ユーザーのすべてのフットプリントを削除（ハード削除）します。したがって、ユーザーが写真を投稿した場合、削除するのはAさんが写真のID 33445を所有していることですが、写真は孤児として保管しています。 （また、ハード削除の場合には、A氏はユーザテーブルから搾取されることになります）。だから、今のユーザーフットプリントを参照しているテーブルは約16個あり、NULLに設定する必要があります。デフォルトのuser_Idは999です。存在しないユーザーを指しています。

B）すべてのフォアプリントとすべてのコンテンツも削除します。したがって、すべて（userIDとobject_iD）はNULLまたは999に設定されています。そして、私がハード削除を行っているなら、私は自分のファイルシステムから写真を物理的に削除する必要があります。

私はこのすべてが制約、トリガー、またはアプリケーション側から処理されているかどうかは確信していませんか？少しのオーバーヘッドでできるだけ簡単かつ迅速に目標を達成することが目標です。

---

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

Answer 1

1. 正しい：ON UPDATE CASCADEは、User_IDが変更できない場合は関係ありません。これはいい。

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-refsする内容が残っている可能性があります。実際にはレコード全体を消去することは非常に困難です。すべての子会社のユーザ情報は、あなたの外部キーにDELETE CASCADEで使用できる、またはあなたは、単に親レコードを削除する前に、補助テーブルから削除することができます削除された場合、真の「ハード削除」については

Answer 2

。

ユーザーレコードを削除するが、副次的な情報（私が一度も見つけたことのないデザイン、btw）を保持する「半ハード削除」では、ON DELETE SET NULLを使用できます。しかし、外部キーの列にNULLを許可するという考えは、私に幸福をもたらします（削除されたレコードであり、既存のユーザーからの "失われた"レコードではないことをどうやって確かめることができますか？）したがって、孤立した情報の周りには、あなたが示唆したように、この情報を格納する特別なユーザーレコードがあります。