2

複数の組織のカスタム分類を必要とするメンバーシップ アプリケーション用のデータベースを設計する必要があります

以下はデータセットです。

  • 組織の種類 1: 名前、電子メール、入社年、終了年、役割、場所。

  • 組織タイプ 2: 名前、電子メール、入社年、終了年、役割、部門、サブ組織、場所

  • 組織タイプ 3: 名前、電子メール、入社年、終了年、役割、識別番号

そのためのデータベースを設計する最良の方法は何でしょうか? いくつかのフィールド項目は一般的で、組織に固有のものはほとんどなく、組織の種類は限られています

オプション1：

  • members_table - member_id、name、email、joining_year、end_year、role
  • members_org_type_1 - member_id、場所
  • members_org_type_2 - member_id、部門、sub_org、場所
  • members_org_type_3 - member_id、id_no

オプション: 2

  • members_table - member_id、name、email、joining_year、end_year、role
  • member_fields - member_id、field_type、field_value
  • field_labels - field_type、field_label

2 番目のタイプは有望に見えますが、必須フィールドを使用して members_table と member_fields 操作を結合する方法がわかりませんか?

4

2 に答える 2

4

これはデータベース設計における一般的な問題であり、対処する最も一般的な方法が 3 つあります (EAV を含めると 4 つ)。

  1. 各タイプに 1 つずつ、3 つの個別のテーブル。

  2. 多数の列を持つ 1 つのテーブル。そのうちのいくつかは Null を持つことが許可されます。整合性はデータベースでは簡単に処理できず (どの列の組み合わせが Null になり、どの列の組み合わせが Null にならないか)、通常はアプリケーションによって処理されます。これは@noaの答えであり、コードがわずかに少なくなり、おそらく（完全ではありませんが）動作するアプリケーションを簡単に作成できます。

  3. 1 つMemberのテーブル (これがスーパータイプ) と 3 つの追加テーブル (サブタイプごとに 1 つずつ)。これにより、組織の種類に応じて、Null を使用せず、使用する列を強制することができます。(これはオプション 1 です)

org_typeすべてのテーブルに列を追加することもできます。これは、追加のUNIQUE制約Member (org_type, member_ID)と、FOREIGN KEY(各サブタイプ テーブルからの) 制約がこのorg_type列を含むように変更されることを意味します。このようなもの：

    CREATE TABLE Member
    ( MemberID 
    , Org_Type
    , Name
    , ...
    , Role
    , PRIMARY KEY (MemberID)
    , UNIQUE KEY (Org_Type, MemberID)
    , CHECK Org_Type IN (1, 2, 3)
    ) ;

    CREATE TABLE Member_Type_1
    ( MemberID 
    , Org_Type
    , Location
    , PRIMARY KEY (MemberID)
    , FOREIGN KEY (Org_Type, MemberID)
        REFERENCES Member(Org_Type, MemberID) 
    , CHECK Org_Type = 1
    ) ;

and finally there's (your option 2) EAV:
  1. Wikipediaによると、Entity-Attribute-Valueモデルは次のとおりです。

エンティティを記述するために使用できる属性 (プロパティ、パラメーター) の数が膨大になる可能性がありますが、特定のエンティティに実際に適用される数は比較的少ないエンティティを記述するためのデータ モデル。数学では、このモデルは疎行列として知られています。EAV は、オブジェクト - 属性 - 値モデル、垂直データベース モデル、およびオープン スキーマとしても知られています。

リレーショナル データベースで EAV を使用しない理由はさまざまです。その主な理由は、データ型と参照整合性に関する問題 (これは簡単に強制することはできません)、単純なクエリでさえも作成するのが難しい (多くの結合で作成される)、および効率性です。DBA.SE の質問で Simon Righarts による回答を参照してください: Is there a name for this database structure?

ただし、Aaron Bertrand の記事で説明されているように、特定の場合に有効なオプションである理由があります。、特に列の数が多い場合や、必要な列が事前にわからない場合 (顧客によるカスタムメイド) はさらに多くなります。組織がカスタム列を追加できるようにしたい場合は、それがあなたのケースかもしれません。

ただし、効率的な EAV モデル/アプリケーションを構築するのは簡単ではないことに注意してください。実際にデータベース内に RDBMS を構築しています。

于 2012-07-14T17:33:41.550 に答える
2

組織の種類が限定されており、めったに変更されない場合は、1 つのテーブルのみを使用してください。

  • members_table - member_id、name、email、join_year、end_year、role、location、department、sub_org、id_no

組織の種類に関係のないフィールドには null 値を使用し、情報を表示するときに該当しないフィールドを非表示にします。

別のデータベース用でしたが、ここで同様の回答をしました。

于 2012-07-14T16:31:31.793 に答える