0

データベースにLogsテーブルがあり、ユーザーアクションのレコードを保存しています。ユーザーIDの列があります。これは、ログが追加されたときにユーザーIDが存在することを確認するためにユーザーテーブルに外部キーが設定されています。ただし、ユーザーを削除しようとすると、ユーザーテーブルに存在しなくなったユーザーIDがログテーブルに残るため、制約が失敗します。ログから問題のある行を削除することはできません。これは、永続的なレコードを保持することが重要であるため(基本的に、誰が何を破ったかを特定できるようにするため)、そのユーザーによるすべてのアクションを削除すると、目的が失われます。

新しいログを挿入するときに(その時点でユーザーが存在することを確認するために)制約をチェックするようにする簡単な方法はありますが、ユーザーを削除するときはチェックしませんか?LINQを介してDBにアクセスしているため、クエリはSQLではなくC#で行われるため、それを必要とするものはすべて削除されますが、MS SQL Server Management Studioを介してデータベースにアクセスできるため、好きなことを実行できます。 。

少し明確にするために編集:誰が行動を起こしたのかを知ることの価値は、説明責任だけではありません。これは、問題がユーザー固有、組織固有、またはシステム全体のいずれであるかを判断するのに役立ちます。これにより、考えられる原因のリストを大幅に絞り込むことができます。ユーザーが削除された後も、アクションを保持する価値があります。たとえば、あるユーザーが特定の組み合わせを実行することによって発生した問題を追跡する場合など、さまざまな理由で、そのユーザーがどのアクションを実行したかを知ることは有用です。 。別々に問題がないが、一方が他方の直後に続くとエラーを引き起こす2つのアクション)。

4

3 に答える 3

0

本当にログを保持したい場合は、ユーザーを完全に削除しないでください。

ユーザーレコードを削除するのではなく、その状態を変更して削除されたことを示します。これにより、データベースの参照整合性が維持されます。

または、カスケード削除をオンにして、ユーザーを削除すると、ログがすべて同時に削除されるようにします。これは、参照整合性を維持するもう1つの方法です。

于 2012-11-08T10:11:09.253 に答える
0

Logsテーブルの主キー(複合キー)をUserIDから独立させることができます。Logsテーブルのインデックス作成方法を変更すると、この問題を解決できます。また、カスケード削除がないことを確認してください。

率直に言って、ユーザーが永久に削除された場合、誰が何を壊したのかを知ることの使用は何ですか?あなたがその人を永遠に悩ませるつもりがないか、そのユーザーをあなたの在庫に巻き込まないようにするつもりでない限り...;)

それ以外の場合、特定のユーザーがシステムから削除された場合、それが有効なオプションである場合は、そのユーザーのログの検索機能を制限できます。

ただし、少なくともUserIDとNameの単純なテーブルを保持することは、まったく悪い考えではありません。

于 2012-11-08T10:19:16.623 に答える
0

誰が何を壊したのか知りたい場合は?削除されたレコードの場合次に、ユーザーテーブルにビットデータ型として「Isactive」列を作成します。ユーザー削除時に、レコードを削除する代わりに、ビット値を「0」に変更できます。ユーザー作成中にそのフィールドを1に設定します。scenerioの唯一のオプションです。

お役に立てれば

于 2012-11-08T10:49:27.113 に答える