既存のデータベースシステムに認証システムを実装しています。現在、データベースには、名、姓、生年月日、電子メール（ユーザー名）などを含む「個人」テーブルがあります。これは、ユーザーのプライマリテーブルです。
認証用に次のフィールドを追加する必要があります：Password、IsLocked、LockDate、LastLoginDate。
これらのフィールドをPersonテーブルに配置することを提案しますか、それとも新しいAuthenticationテーブルに配置しますか？私の当初の計画は、「個人」に、必ずしも認証に関するものではなく、その個人に関するデータを含めることでした。
もう1つの方法は、パスワードを電子メールと一緒にPersonに保存し、認証データを別のテーブルに配置することです。このように、ユーザー名とパスワードは同じ場所にありますが、メタデータは独自のエンティティにあります。
誰か考えがありますか？助けてくれてありがとう！
Personユーザーがアカウントのクレデンシャルにアクセスしなくても、システムに情報を照会できるように、それらを分離してください。
Personこれには、すべてのエンティティがアカウントを持っているとは限らないという優れた副作用もあります。
アカウント情報は別にしてください。現在のビジネス要件は、各人が1つのアカウントのみを持つことですが、将来的には、1人が複数のアカウントを持っている必要がある場合や、複数の人が共有するアカウントが必要になる場合もあります。認証用に別のテーブルがあるということは、そのような将来の変更がコードに与える影響が小さいことを意味します。
また、認証情報を保護するという観点から、アカウントデータにアクセスできる人/プロセスが少ないほど良い結果が得られます。列レベルのアクセスよりもテーブルレベルのアクセスを実装する方がはるかに簡単です。
認証データ用に別のテーブルを作成することはあまり意味がないと思います。私の知る限り、認証は個人から独立して存在することはできません。また、1人の個人を2つの認証に合理的に関連付ける方法はないようです（またはその逆）。
言い換えると、個人と認証の間には1：1の関係があるのに、なぜそれを分割するのでしょうか。