3

私のデータベースには、、、などのさまざまなエンティティがありtodosます。それぞれに、、、、およびその他の関連アイテムを含めることができます。eventsdiscussions
tagscommentsfiles

次に、これらのテーブル間の関係を設計する必要があります。次の 2 つの可能な解決策から選択する必要があると思います。

1. 分離された関係テーブル

todos_tags、events_tags、discussions_tags、todos_comments、events_comments、discussions_commentsなどのテーブルを作成します。

2. 共通関係表

これらのテーブルのみを作成します: related_tags、related_comments、related_filesなど。次のような構造を持ちます。

関連タグ

  • entity(event|discussion|todo|etc. - enum または tinyint (1|2|3|etc.) として)
  • entity_id
  • tag_id

どのデザインを使用すればよいですか?

おそらくあなたはこう言うでしょう：それは状況次第ですが、私はこれが正しいと思います。

私の場合、ほとんどの場合 (おそらく 70% 以上)、エンティティ (イベント、ディスカッション、または Todos) の 1 つだけを照会する必要がありますが、場合によっては、それらすべてを同じクエリ (イベント、ディスカッション、Todos の両方) で必要とします。たとえば、指定されたタグを持つ)。この場合、別の関係テーブルを使用する場合は、3 つ以上のテーブル (私の場合は 5 つ以上のテーブル) でユニオンを実行する必要があります。

各テーブル (イベント、ディスカッション、仕事) に 1000 ～ 2000 行を超える行はありません。

正しい方法は何ですか？これについての個人的な経験は何ですか?

4

2 に答える 2

2

2 番目のスキーマはより拡張可能です。このようにして、アプリケーションを拡張して、複数のタイプを含むクエリを作成できます。さらに、新しいタイプを将来的に動的に追加することも簡単にできます。さらに、集計の自由度が高くなります。たとえば、各タイプに存在する行数や、特定の時間枠で作成された行数を数えることができます。

一方、最初の設計には、速度以外に多くの利点はありません。しかし、MySQL は、これらのタイプのクエリを十分に高速に処理することができます。インデックス「エンティティ」を作成して、スムーズに機能させることができます。将来、速度を上げるためにテーブルを分割する必要がある場合は、後の段階で行うことができます。

于 2012-10-16T08:39:49.450 に答える
2

複数のテーブルを使用するよりも、列でエンティティ タイプを指定する related_tags などの単一の共通関係テーブルを使用する方が、はるかに単純な設計です。最適なパフォーマンスを得るために、entity フィールドと tag_id フィールドを一緒に適切にインデックス化するようにしてください。

于 2012-10-16T08:44:34.120 に答える