0

私たちの会社はCRMを開発しており、関係をどのように処理したいかを決定しなければならないところまで来ました. 数が多いので重要なポイントです。そして、後で構造を変更することは、単にクールではありません..

私はそれを行う方法を 3 つ知っています。

1 つの関係テーブル:

私がこれを行う方法は、すべての関係を保持する 1 つのテーブルを作成することです。

Table: releationships

+----+-------------+-----------+--------------+------------+
| id | record_type | record_id | belongs_type | belongs_id |
+----+-------------+-----------+--------------+------------+
| 1  | person      | 42        | company      | 12         |
+----+-------------+-----------+--------------+------------+
| 2  | person      | 43        | company      | 12         |
+----+-------------+-----------+--------------+------------+
| 3  | note        | 23        | company      | 12         |
+----+-------------+-----------+--------------+------------+ 
| 4  | attachment  | 13        | company      | 12         |
+----+-------------+-----------+--------------+------------+

複数の関係テーブル:

これは、たとえば SugarCRM が行う方法だと思います。

Table: company_realationships

+----+-----------+------------+--------+
| id | record_id | has_type   | has_id |
+----+-----------+------------+--------+
| 1  | 12        | person     | 42     |
+----+-----------+------------+--------+
| 2  | 12        | person     | 43     |
+----+-----------+------------+--------+
| 3  | 12        | note       | 23     |
+----+-----------+------------+--------+
| 2  | 12        | attachment | 13     |
+----+-----------+------------+--------+

レコード テーブル内のすべて:

Table: person

+----+-----------+------------+
| id | name      | company_id |
+----+-----------+------------+
| 42 | luke      | 12         |
+----+-----------+------------+
| 43 | other guy | 12         |
+----+-----------+------------+

など。

  • だから私の質問は、多くの関係を処理する最良の方法はどれですか?
  • それを行う他の方法はありますか？
  • デメリット・メリットとは？
  • トラフィックの多い側が関係を処理する特別な方法はありますか?

助けてくれてありがとう:)

4

1 に答える 1

3

だから私の質問は、多くの関係を処理する最良の方法はどれですか?

3 つ目またはそのバリエーション (以下を参照)。

すべての "M:N" 関係は、独自のジャンクション テーブルで表す必要があります。OTOH、「1:N」関係には追加のテーブルは必要ありません。「N」側のテーブルに適切な外部キーがあるだけです。

あなたの説明を正しく理解できれば、3 番目のオプションは会社と個人の 1:N の関係をモデル化します。万が一、それらの間の M:N 関係をモデル化したい場合は、ジャンクション テーブルが必要ですcompany_person ( company_id, person_id, PK (company_id, person_id) )。

それを行う他の方法はありますか？

場合によっては、継承 (別名、カテゴリ、サブタイプ、汎化階層など) を使用して、可能な「関連する」組み合わせの数を減らすことができます。簡単に言えば、親との関係を作成すると、その親から継承されたすべての子が自動的にその関係に関与します。

例として、この投稿を見てください。

デメリット・メリットとは？

制約 (FK を含む) を宣言的に適用することは、トリガーを介してそれらを適用するよりも優れています (エラーが発生しにくく、おそらくパフォーマンスが向上します)。これも、クライアント コードで適用するよりも優れています。

その原則により適したデザインを選択してください。たとえば、オプション 1 と 2 では、DBMS が FK を宣言的に強制することはできません。

トラフィックの多い側が関係を処理する特別な方法はありますか?

優れた論理設計とそれに続く優れた物理実装が、優れたパフォーマンスの唯一の強固な基盤です。悪い設計の上にパフォーマンスを「追加」するのは困難です。

おそらく、あなたは見てみたいと思うでしょう：

そして、パフォーマンスに関しては、推測しないでください。現実的な量のデータを測定します。

于 2012-11-21T18:36:42.847 に答える