参加/リンク/多対多のテーブルのガイドライン

Question

私はこれを行うための最良の方法について私自身の理論を持っていますが、共通の話題と思います。ここに行く

多対多のジョイン・テーブルを扱う最良の方法は何ですか？それらの名前の付け方、関係に特別な情報を追加する必要があるときの対処方法、実行時の対処方法2つのテーブル間の複数の関係

ユーザーとイベントの2つのテーブルがあり、出席者を保存する必要があるとします。したがって、EventAttendeesテーブルを作成します。オーガナイザーを保管するための要件が​​発生します。あなた

1. がEventOrganisersテーブルを作成する必要がありますので、それぞれの新しい関係が結合テーブル または
2. でモデル化されUserEventRelationship（またはUser2EventまたはUserEventMapまたはUserToEventのようないくつかの他の名前、）、およびIsAttending列にEventAttendeesの名前を変更そして、IsOrganiser欄にあなたが2人の参加者 または
3. 両方のビット間のすべての関係情報を格納する単一のテーブル持っている、すなわち、（本当に？）を他の または
4. 何か完全に？

考えられますか？

Answer 1

このような一般的な質問に対する簡単な答えは、いつものように「すべてが詳細に依存します」です。

一般的に、データ定義を過度に乱用することなくこれを行うことができる場合、私は少ないテーブルを作成しようとします。あなたの例では、isOrganizerカラムをテーブルに追加するか、おそらく観客/主催者からオーディエンス/オーガナイザー/スピーカー/出席者へ、または必要に応じて将来の拡張を容易にするattendeeTypeを追加します。基本的に同一の列を持つ余分な表を作成すると、表名が有効なフラグが「出席者のタイプ」を特定するために、私は元のデザインの観点からも実用的な観点からも間違った方法に見えます。

単一のテーブルはより柔軟です。 1つのテーブルとタイプフィールドで、単に計画主義への招待状を送るときのようにオーガナイザーだけを知りたければ、「usereventからuseridを選んでください」と書いておきます。ここで、eventid =？とattendeetype = 'O' "ランチテーブルの名刺を印刷しているときのように、そこにいるすべての人を知りたい場合は、出席者テストを含めないでください。

しかし、2つのテーブルがあるとします。その後、オーガナイザーだけが必要な場合は、オーガナイザーテーブルに参加するのは簡単です。しかし、オーガナイザとオーディエンスの両方が必要な場合は、より複雑なクエリを作成し、通常は遅くなるユニオンを実行する必要があります。そして、あなたが思っているのであれば、大規模な組合は何ですか？という質問には、さらに多くのことがあるかもしれません。多分、人は複数の電話番号を持つことができ、私たちはこれを気にしているので、クエリは単にuserとeventAttendeeに参加するのではなく、電話にも参加します。たぶん、私たちが "卒業生"に特別な取引をしているので、彼らが以前の会議に参加したかどうかを知りたいかもしれませんので、eventAttendeeにもう一度参加しなければなりません。組合との10テーブルの参加は、読む。