これは設計上の問題です。
ユーザー テーブル {UserKey, UserName} があり、ユーザー アクティビティをログに記録しているとします。そのため、ログ テーブル {UserKey, Activity} には、UserKey 列があります。ログテーブルの UserKey をユーザーテーブルの外部キーにするのは良い考えですか?
私が見る限り、
長所 (ForiegnKey): ダングリング レコードがありません。
短所（ForiegnKey）：ログも削除しない限り、ハード削除はできません。これは明らかに悪いことです。
あなたの提案は何ですか？他に何が欠けていますか？
短所（ForiegnKey）：ログも削除しない限り、ハード削除はできません。これは明らかに悪いことです。
まず第一に、これは「明らかに」悪いことではありません。これは、ダングリング レコードを処理する 1 つの方法にすぎません。ところで、クライアント コードから実行する必要はありません。ON DELETE CASCADE 参照アクションを介して自動化し、DBMS に実行させることができます。
もう 1 つは、NULL 可能な FK を使用することです (場合によっては ON DELETE SET NULL を使用します)。
データベースに存在しなくなったユーザーに関連付けられているレコードを保持することはできません。ダングリング レコードはユーザー キーを保持する場合がありますが、そのキーはもはや意味がなく、新しいユーザーが再利用することさえできます (自動インクリメント ID を使用している場合はそうではありませんが、それでも可能です)。
しかし、ユーザーを「引退」させ (たとえば、ユーザー テーブルにフラグを設定することにより)、彼女のすべての記録を保持し、古すぎてもはや問題にならない引退したユーザーをクリーンアップするバックグラウンド プロセスを潜在的に持つことができます。
いずれにせよ、FK はダングリング レコードを防止する方法であり、私はそれを放棄することは非常に気が進まないでしょう。適切なインデックス付けがあれば、パフォーマンスの問題はないはずです。問題があると思われる場合は、他のことを行う前に、実際に問題があることを測定して確認してください...
あなたの問題には複数の解決策があります。1. logically deleteユーザーがデータをそのまま保持することも、2. log the user key onlyログ テーブルに保存することもできます。
最初のソリューションは、少数または中程度の数のユーザーがいる場合に最適です。ただし、パフォーマンスのマイナス面があります。アプリケーションが大きくなり、ユーザー数が増えると、Users テーブルにはまだアクティブでないユーザーが残り、それらのレコードによってデータベースの応答が遅くなります (たとえば、ログイン操作中)。 .
2 番目の解決策は、アプリケーションが時間の経過とともに持つユーザーの数に関係なく、適切です。ただし、削除したユーザーのデータは失われます。したがって、5 年前に何らかのアクティビティを行って削除されたユーザーの詳細を知ることはできません。
3 番目の解決策があります。3. using table 'UserArchive'
これは、最初の解決策の利点を組み合わせて、2 番目の解決策の問題を回避します。アプリケーションに存在するすべてのユーザーのデータを含む UserArchive という新しいテーブルを作成できます。Log テーブルを UserArchive テーブルにリンクすると、Users テーブルにユーザーが存在しなくなっても、何らかのアクティビティを行ったすべてのユーザーのデータが得られます。
ユーザーが登録すると、必要な詳細を Users テーブルに追加し、いくつかの重要な (またはすべての) 詳細を UserArchive テーブルに追加できます。（データの冗長性に注意してください。これがデータベースにとって良いか悪いかはあなた次第です）ユーザーがアカウントを削除したい場合、重要な（またはすべての）詳細がUserArchive に保存されます。
アドバイス: 論理的な観点からは必要ないため、Users テーブルを UserArchive に接続しないでください。
どのソリューションがアプリケーションに最適かは、あなた次第です。