3

次のテーブルがあります: - 投稿 - ファイル - イベント - ドキュメント

すべての投稿、ファイル、イベント、ドキュメントにコメントを付けることができます。

これに適したデータベース スキームは何ですか?またその理由は何ですか?

最初の解決策

  • コメント テーブル (comment_id、author_id、comment)
  • リレーションを作成するための 4 つのテーブル (posts_comments(post_id, comment_id)、files_comments(file_id、comment_id)、events_comments(event_id、comment_id)、documents_comments(document_id、comment_id))

2 番目の解決策

  • コメント テーブル (comment_id、author_id、comment)
  • items_comments (comment_id、parent_type (enum['post'、'file'、'event'、'document'])、parent_id)

これに対するより良い解決策は何ですか、または2つのうちどちらを使用する必要がありますか?

4

3 に答える 3

2

単一のコメント テーブルが必要な/必要な本当の理由があるかもしれません。たとえば、特定のユーザーからのすべてのコメントを簡単に表示できます。また、すべてのコメントの検索がより簡単になります (1 つのテーブルに 1 つの FTS インデックスを配置すれば完了です)。

一方、コメントを 1 つの表に収めるやむを得ない理由がない場合は、3 番目の (そしてかなり明白な) 解決策が考えられます。

アイテム (投稿、イベント、ファイル、ドキュメント) ごとに個別のコメント テーブルを作成します。そのような状況では、RI 関係を定義して説明するのは非常に簡単です。また、アドホック クエリを頻繁に入力する場合は、より簡単になる可能性があります。例えば

 select * from documents d left join doc_comments c 
                           on d.id = c.docid 
                           where d.id=42;

これはどれもあなたの状況に関連したり重要ではないかもしれませんが、検討する価値があるかもしれません.

追加のランダムな考え: OP の両方のソリューションには、多対多の関係を定義しているという "感覚" があります (たとえば、コメントは複数のアイテムに属することができます)。それが望ましい状況ではないと仮定すると、適切な一意のインデックスで防ぐことができます...しかし、それでも...最初の外観があり、混乱を招く可能性があるようです.

于 2012-05-15T16:27:34.987 に答える
1

私は最初の解決策を好むでしょう。Sql-Statements はより単純です。そして私の意見では、データベースの正規化により準拠しています

于 2012-05-15T14:16:16.597 に答える
1

完全を期すために、別の可能性について言及する必要があります-継承（別名、一般化または（サブ）カテゴリ階層）：

ここに画像の説明を入力

于 2012-05-15T19:52:03.857 に答える