残りのアプリケーションサーバー用に単一のデータベースを実行しています。私たちは、管理者のための顧客 ユーザーポータルとお客様のWebサイトを処理するスキーマ内の単一ユーザーテーブル
は現在、彼らが異なるテーブルとユーザー名とパスワードは別々でもあるしているパートナーのため
UserとRoleテーブルが1つあればOKですか？ （ここでRoleは管理者、パートナーまたは顧客、マネージャになることができます）。 OR
我々はユーザーおよびロールテーブルを使用する場合、我々は問題を持つことになるとして、それがあるとして、私たち維持する必要があります：
、管理することができます。あなたの提案は何ですか？
はい、次の理由により別のテーブルを保管する方がよいでしょう。
1.指定したとおり、顧客は役割ではありません。
2.管理者の数には制限があるため、顧客を持つ大量のデータセットからの認証/承認のためのレコードを取得する必要はありません。それはパフォーマンスを妨げるでしょう。
ユーザー
ID
のuserId
役割（外部キー）
など。
役割
ID
名
など
上記構造がベストです実践的e。 あなたが本当に管理者、パートナーや顧客のための余分なフィールドが必要な場合 あなたがそれぞれに対して別々のエンティティを作成することができますし、
カスタマー
ID
名
を次のようになどの外部キーとしてユーザーを参照することができます
など
私はあなたのユーザー管理のために、1人のユーザーが複数の役割を持つことができるという事実を考慮して、3つのテーブルを作成すべきだと思います。（例： - adminもマネージャーかCustoマーはパートナーになることもできます）。そのため、ユーザー表と役割表には多対多の関係があります。この関係を作成するには、userIdとroleIdを複合プライマリキーとして持つ3番目のテーブルを作成する必要があります。
さらに、ユーザーのパスワードをデータベースに保存することに気付きました。セキュリティ上の理由から、パスワードはプレーンテキストで保存しないでください。 Instaedは、一方向ハッシングアルゴリズムを使用してパスワードのハッシュを格納します。 あなたはそれについてもっと読むことができます - >Best way to store password in database
BCryptを使用してパスワードを保存していません。しかし、問題は、ユーザーadminまたは顧客またはパートナーが同じユーザー名を取得できるため、役割を持つ単一の表を作成することです。私たちはまた、ソーシャルネットワークのログインをしているので、userIdに対して同じソーシャルネットワークID（fbまたはgmail）を持つことができます。私たちはそれらを管理するためにジレンマに陥るでしょう。 –
表の設計では、数値の主キーを使用してください。この場合、ユーザーテーブルの主キーとして自動インクリメントユーザーIDを使用します。ユーザーを一意に識別するには、ユーザーを登録するときにユーザーの電子メールアドレスを収集します。だから、あなたは社会的なログインを使用するときに他のユーザーとの競合について心配する必要はありません。最初にソーシャルログインを使用するときは、データベースにユーザーの詳細を追加することを忘れないでください。 –
あなたはその答えの背後にある考えを捉えていませんでした。すべてのユーザーログインがパスワードハッシュ（およびその他の詳細）として含まれていますが、役割に関する情報（ユーザーと呼ばれます）はありません。特定のユーザーが実際に持っているルールの数に関係なく、ユーザーごとに1つのエントリがあります。次に、すべての可能な役割（役割と呼ばれる）を列挙した表。ここには、顧客用、管理者用、パートナー用の3つの行しかありません。次に、どのユーザーがどの役割を持ち、同じユーザーに複数の役割が割り当てられているかを知らせる3番目の表があります。 – Ister
私はユーザー名とパスワードを保持しますか？ユーザテーブル内でのみですか？ –
@ JohnnyMartinはい、あなたはユーザーテーブル自体にユーザー名とパスワード（暗号化された）を保持できます。 –
あなたのデザインごとに、多くの役割を持つことはできませんが、私たちはただ一つの役割しか持っていません。代わりに私はそれがuser_typeテーブルになるので、誰もがそのユーザーがシングルタイプであることを理解することができます。 –