複数の振る舞いを持つ文書表のデータベース設計に関する意見

Documentは、originとdestinationの間のトランザクションに関するすべての情報を保持する構造体です。 originとdestinationの両方は、companyまたはpersonの2つのタイプにすることができます。このようなユースケースをモデル化する最良の方法は何ですか？複数の振る舞いを持つ文書表のデータベース設計に関する意見

1Nºアイデア：

Document 
**document_columns** 
origin_id -> foreign key 
origin_type -> customer or person 
destination_id -> foreign key 
destination_type -> customer or person

アイデア2Nº：

Document 
**document_columns** 

DocumentOrigin 
document_id 
origin_id 
origin_type 

DocumentDestination 
document_id 
destination_id 
destination_type

アイデアNº3：おそらく別の上で1つを選択する影響を与える可能性が

DocumentCompany 
**document_columns** 
company_id 

DocumentPerson 
**document_columns** 
person_id

物事は必要なことです同じであるかのようにすべてDocumentsを集めるレポート。 UNIONまたはその他の高度なSQLコマンドを使用してスキーマに関する情報を生成することも考慮する必要があります。

出典

2017-07-20 MurifoX

原点タイプは、原点または文書トランザクションに依存していますか？原産地に依存している場合は、文書トランザクション –

に入れないでください。基本表と1対1の関係を持つ個人および社内表を作成し、文書の外部キーをこの表に使用することをお勧めします。起点/目的地タイプの欄が冗長になります。 –

すでに会社と人のテーブルがあるとします。 CompanyIDとPersonID外部キーを持つアクター・テーブルを作成できます。Personの場合はPersonIDに値があり、そうでない場合はnullになります。それが会社の場合、CompanyIDは値を持ち、それ以外の場合はnullになります。したがって、あなたはActorID（CompanyID、PersonID、...）、Company（CompanyID、...）、Person（PersonID、...）、Document（DocumentID、OriginID、DestinationID）を持ちます。 OriginIDが起点者/会社を参照し、DestinationIDが宛先人/会社を参照するActorテーブルの外部キーとなります。

出典

2017-07-20 13:17:26

これは、多くのLEFT JOINSノーとなるでしょうか？私が起源または目的地の名前を取得したい場合。 gistを参照してください：https://gist.github.com/murparreira/c2c3f8780c138cefefab223e500b60ab – MurifoX

@MurifoXそれが会社か人かを知っているときは、左の結合の数を減らすことができます。それを事前に知らなければ、そうする必要があります。一般的なフィールドはActorテーブルに格納する必要があります。したがって、CompanyやPerson固有のものが必要ない場合は、結合なしでも実行できます。 –

複数の振る舞いを持つ文書表のデータベース設計に関する意見

答えて

関連する問題