フロントエンドユーザーと同じテーブルに管理ユーザーを配置するのは良いデータベース設計ですか？
フロントエンドページにログインできるユーザーと、管理ページにログインできる管理者がいます。
ユーザーと管理者の両方が異なる役割を持つ「ユーザー」である必要がありますか、それとも異なるテーブルに分割する必要がありますか？
時間の経過とともに誰かが昇格（または降格）される可能性があるため、役割はユーザーアカウントとは別に追跡する必要があります。その状況では、2つの異なるテーブルに2つの異なるユーザーアカウントを持つことは理にかなっていますか？私はそうは思いません。
これが私が使用する基本的な構造です-
ユーザー
- user_id（主キー）
- user_name
ロール
- role_id（主キー）
- role_name
USER_ROLES
- user_id（主キー、USERS.user_idへの外部キー）
- role_id（主キー、ROLES.role_idへの外部キー）
はい、すべてのユーザーがユーザーテーブルに属しています。また、Rolesテーブルがあり、2つの間にFKが必要です。
管理者とユーザーがフィールドを共有している場合は、構造が重複しないように同じテーブルに入力する必要があります。どちらにも名と姓があります。どちらも実世界では人間です。これはおそらく本来あるべき姿です。
しかし一方で、州と都市にはどちらも名前があります。そしてどちらも場所です。彼らはいつも同じテーブルに行くべきですか？時々それらは再帰モデルで行います。時々それらは分かれています。
私の考えは......管理者はあなたのシステムのユーザーの「タイプ」であると考えられていますか？それとも、「ユーザー」タイプのどれもが適用されない、本当に何か違うのでしょうか？これは、システムで管理者が実際に何を意味するかによって異なります。共有構造は都市/州の境界線に沿っていますか？または、「あなたはTYPEユーザーです」という説明に沿った共有構造ですか？
しかし、疑わしい場合は管理者をユーザーテーブルに配置することを検討してください。管理者が本当に別だとは思わないからです。おそらく両方の認証システムを共有したいと思うでしょう。おそらく両方のアカウント作成を共有したいと思うでしょう。 adminが特別なものでない限り、開発者だけがバックエンドで使用します。
ユーザーが誤って管理ユーザーになった場合のリスクは、ユーザーが誤って別のユーザーになった場合よりも大きくなるべきではありません。
通常のユーザーと管理ユーザーが別々のテーブルにある場合、通常のユーザーテーブルのユーザーIDが管理ユーザーテーブルのユーザーIDと一致することを考慮してください。 1つのタイプのユーザーIDが他のタイプとして誤って決して使用されないようにする必要があります。このような問題を特定することは、ユーザーIDを別のユーザーIDに変更させる原因を見つけることよりも困難です。
個人的には、「ユーザー」を1つのテーブルにまとめます。 （たとえば、ユーザーテーブル自体の静的ビットとして、または高度なRBAC権限を通じて）ロールをどのように表すかを決定する方法は、システムの複雑さによって異なります。しかし、ユーザーはユーザーです。
私はあなたの質問について絶対的な真実はないと信じています、それはあなたのアプリケーションに依存します。
ユーザータイプcouldが異なるテーブルにある2つの理由は次のとおりです。
- タイプはデータ構造が異なります（詳細/住所など）
- 良い睡眠。 FK値を手動で編集する（ユーザーを指す）場合、フロントエンドユーザーに何かを指すリスクを回避できます。
別のRolesテーブルと別のUser_Rolesテーブルを作成します。最初に役割を定義し、2番目にユーザーをそれぞれの役割に参加させます（ユーザーが複数いる可能性はありますか？）
ユーザーを保持する場所に問題はありません。問題は、その情報にアクセスするためのpages\methodsのみです。
同じデータ型を保持しているため、実際には両方を同じテーブルに保持する方が適切です。
データの観点からは、管理者がさまざまな役割を持つユーザーであることは理にかなっています。各ユーザー権利のテーブルがあり、ユーザーと役割を関連付けます。ユーザーはそのような複数の役割を持つことができますが、結局のところ、管理者はユーザーです。