webdevqa.jp.net

データベース設計:3種類のユーザー、個別のテーブルまたは1つのテーブル?

3種類のユーザーがいます。

  • 管理者
  • サプライヤー
  • 従業員

各ユーザータイプには異なるユーザーインターフェイスがあり、異なるタイプのデータにアクセスします。唯一の類似点は、1つのWebアプリケーションを使用していることですが、まったく異なるものにアクセスします。それらをすべてtbl_usersのように1つのユーザーテーブルに配置する方が良いでしょうか、それともtbl_admins、tbl_suppliers、tbl_employeesを作成する方が良いでしょうか?

49
IMB

テーブルを設計するときに考慮する必要があるのは、必ずしもそれらがアクセスできるものではなく、それがどのように類似/非類似であるかではなく、ユーザーレベル自体がどのように類似/非類似であるかです。

たとえば、ユーザータイプの属性(名前、電子メール、誕生日など)が同じ場合、それらは特権レベルを示す列とともに1つのテーブルに属します。

これにより、ユーザーの特権レベルの変更も容易になります。たとえば、ユーザーテーブルのレコードを更新するだけで、通常の従業員を管理者にすることができます。

サプライヤが他の2つとは異なる属性を持つ異なるタイプのオブジェクトである場合、サプライヤは独自のテーブルに属する可能性があります。

または、もう1つ考慮すべき点は、3つのタイプすべてのユーザーに関する非常に限られた情報のみを保持するusersテーブルを使用することです。メインusersテーブルに戻る外部キーを持つ他のテーブルにそれらを保存できます。

62

3番目の選択肢もあります。すべてのユーザーが共通に持つ列をtbl_usersに入れ、tbl_adminstbl_suppliers、およびtbl_employeesに3つのテーブルを作成して、tbl_usersに1対0..1として参加します。共有列の数が重要な場合は、この選択を代替として考慮する必要があります。

11
dasblinkenlight

データ構造がどれほど似ているかによります。それらが類似している場合は、おそらくすべてを1つのテーブルに入れることができます。しかし、それらに多くの異なるフィールドがあり、多くのNULL値で終わる場合...そして、それらはすべて別々のテーブルにある方が良いです。

2
Aaron

すべてのログイン情報を1か所に保管するのが最善です。ログインプロセスを変更する場合、3つの異なるテーブルがあると、3つの別々の場所でコードを変更する必要があります。

ユーザーが複数のロールに所属できる場合は、UserRolesテーブルの作成を検討してください。そうでない場合は、RoleTypeなどの既存のテーブルにフィールドを追加すると、さまざまなタイプのユーザーを区別するのに役立ちます。

0
pjbrown88

それらを1つのテーブルに含めて、ユーザーが管理者、サプライヤー、または従業員であるかどうかを示すフィールド/属性を作成する必要があります。

そのように集中化する方が簡単です。

どのように/何にアクセスするかについての懸念は、開発するソフトウェアの下にあります。所有するユーザーのタイプに基づいて、UI(またはソフトウェアシステムでアクセスするもの)を取得または制限できます。

私は通常、持っているユーザーのタイプに応じて、ものを隠したり表示したりします

お役に立てれば..

0
divi