私は学生のレコードを作成したか、誰が、特定の従業員レコードを作成した人のような監査を持ちたいUserAccountのテーブルと従業員、学生などのような他のテーブルを持っています。従業員、学生などの他のすべてのテーブルでUserAccountIdを外部キーとして使用するのがよい方法ですか？私はこのようにマップした場合、私はUserAccountと他のすべてのクラスとの間の関係を1対多に維持しなければならないので、コードが増加し、負担になるので、私は休止状態を使用しています。UserAccount TableをSQL Serverの他のすべてのテーブルとマッピングすることをお勧めしますか？
それはすべての正規化ルールを破ります。代わりにリンク/ hrefテーブルがあります。 UserAccountID、EmployeeID（NULL）、StudentID（NULL）。このような1つの大規模なリンクテーブルを持っています。外部キーは、UserAccountID（主キーと外部キー）のほかにnullableである必要があります。
「良い習慣/練習」は主観的です。
エンティティを作成した人物が意味のある情報であり、エンドユーザーによる通常の要求である可能性が高いという事実がビジネスドメインに含まれている場合、テーブル/テーブルに "createdBy"クラスは、実際には良い習慣です。
これが本当かどうかを知る最良の方法は、「ユーザーxによって作成されたすべての従業員」を示す画面が必要かどうかを製品の所有者に問い合わせることです。彼らが「いいえ、何かが間違っている場合にのみ」と言うならば、あなたは監査要件を持っています。彼らが「はい、我々はそれを定期的に使用する」と言っても、あなたのビジネスドメインの不可欠な部分です。
ユーザーは、行を作成した人だけでなく、変更した人も知りたいと思うことがあります。その場合、SOについても同様の質問があります。