私は多くの Web アプリを作成しました。最初に行うことは、ユーザー名、パスワード、名前、電子メール、およびその他の通常のすべての flotsam を含むユーザー テーブルを作成することです。私の現在のプロジェクトは、非ユーザー レコードがユーザーと同様に機能する必要がある状況を示していますが、一次ユーザーになる能力は必要ありません。
people_tbメインのリレーショナル テーブルおよびデータ ストアである 2 番目のテーブル を作成し、users_tbを認証のみに使用することは合理的ですか? user_tbからの分離はpeople_tb何か問題がありますか? これが一般的に行われている場合、いくつかの戦略と解決策、および欠点は何ですか?
データベースを正規化しているので、これは確かに良い考えです。私が書いているアプリで同様の設計を行いました。そこでは、従業員テーブルとユーザー テーブルがあります。ユーザーは外部の会社または従業員の場合があるため、従業員は常にユーザーですが、ユーザーは従業員ではない可能性があるため、別のテーブルを用意しています。
遭遇する問題は、user テーブルを使用するときはいつでも、表示したい名前やその他の共通属性を person テーブルに取得させたいということです。
コーディングの観点から言えば、単純な SQL を使用している場合、select ステートメントを頭の中で解析するにはもう少し労力が必要です。ORM ライブラリを使用している場合は、もう少し複雑になる可能性があります。私はそれらについて十分な経験がありません。
私のアプリケーションでは、Ruby on Rails で書いているので、employee.user.name のようなことを常に行っています。これらをまとめると、employee.name または user.name になります。
パフォーマンスの観点からは、1 つではなく 2 つのテーブルにヒットしていますが、適切なインデックスがあれば、無視できるはずです。たとえば、主キーと個人名を含むインデックスがある場合、データベースはユーザー テーブルにヒットし、次に個人テーブルのインデックスにヒットします (ほぼ直接ヒットします)。 1つのテーブルを持つこと。
データベースにビューを作成して、両方のテーブルを結合したままにして、パフォーマンスをさらに向上させることもできます。Oracle の新しいバージョンでは、必要に応じてビューにインデックスを付けてパフォーマンスを向上させることもできます。
私にとって「ユーザー」（ユーザー名、パスワード、作成日、最終ログイン日）の概念は「人」（名前、住所、電話、電子メール）とは異なるため、私は日常的にそうしています。あなたが見つけるかもしれない欠点の1つはあなたが探している情報を得るためにあなたのクエリがしばしばより多くの結合を必要とするということです。ログイン名だけを持っている場合、たとえば、名前と名前を取得するには、「people」テーブルに参加する必要があります。すべてをユーザーIDの主キーに基づいている場合、これは少し軽減されますが、それでもポップアップします。
user_tbに認証情報がある場合は、それをpeople_tbとは別にしておくとよいでしょう。ただし、私は2つの関係を維持し、認証に必要なすべての情報を除いて、ほとんどのユーザーの情報はpeople_tbに保存されます（これは他の多くの目的には使用されないと思います）。設計と効率の間の優れたトレードオフです。考える。
何百万人もの人の記録と数千人のユーザーしかいないので、それは間違いなく私たちがしていることです. また、住所、電話番号、電子メールをリレーショナル テーブルに分けています。これは、多くの人がこれらをそれぞれ 1 つ以上持っているためです。名前は一意ではないため、識別子として名前に依存しないことが重要です。名前ではなく、ある種の代理キー (整数または GUID が望ましい) によってテーブルが結合されていることを確認してください。
非常に合理的です。
例として、ここでaspnet_*サービステーブルを見てください。
それらの組み込みスキーマにはとがありaspnet_Users、aspnet_Membership後のテーブルには特定のユーザーに関するより拡張された情報（ハッシュされたパスワードなど）がありaspnet_User.UserIDますが、スキーマの他の部分では参照整合性などのために使用されます。
結論として、あなたの場合のように、属性が異なるエンティティである場合、属性を別のテーブルに含めることは非常に一般的で優れた設計です。
私は常に、できるだけ多くのデータの繰り返しを避けるようにしています。すべての人がログインする必要がない場合は、people人とユーザーの両方に適用される情報 (名、姓など) を含む一般的なテーブルを作成できます。
users次に、ログインした人に対して、 と 1~1 の関係を持つテーブルを作成できますpeople。このテーブルには、ユーザー名とパスワードを格納できます。
正規化された設計 (2 つのテーブル) を使用し、非正規化 (1 つの user/person テーブルに下げる) だけを行うと、将来の作業が本当に楽になる場合に限られます。ただし、実際にはすべての人がユーザーでもある場合は、前もって非正規化する方が簡単かもしれません。それはあなた次第です; 問題なく正規化されたアプローチを使用しました。