結合テーブルと型フィールドのトレードオフ

Question

私は、他の複数のテーブルに関連するテーブルを持つデータベースの設計について洞察しています。特定の例は、さまざまな種類のものにコメントを付けるサイトです。人々が記事にコメントしたり、写真にコメントしたり、コメントを投稿したりできます。

この表現するための二つの方法があるようです：お互いのテーブル TABLESのテーブル結合）

1：

• 記事
• articles_comments
• コメント
• comments_peopleを
• comments_photos
• 人
• 写真

または 2）

• 記事
• コメント
• 人
• 写真

であり、コメントテーブルには、「タイプ」フィールドと、もう一方のテーブルにリンクするitem_idがあります。

第1のアプローチはより適切であると思われますが、第2のアプローチでは表が少なく、ある点ではよりシンプルになるかもしれませんが、FK拘束を使用することができます。item_id複数のFKに関連する可能性があります（AFAIK - mysql innodbを使用）。私たちのアプリケーションでは、複数の関係（コメント、写真など）を持つ2-3個の表と、関係を必要とする5〜10個の表が存在する可能性はありません。

私はアドバイスを探していますが、より良いアプローチです。

Answer 1

typeカラム（enum btw）を持つテーブルは、将来「コメント」が何であるかを進化させたい場合があるので、より良いアプローチのようです。

説明したような4つのテーブルを持つことで、Modelクラスのフィールドとその関係が簡単になります。

コメントテーブルに 'LEFT JOIN'を使用する場合は、0から多への関係です。それ以外の場合は 'INNER JOIN'です。

お楽しみください。

Answer 2

私は個人的にオプション＃2が嫌いです。これは、議論の的題とは何かを表す、一つの大きなルックアップテーブル概念。

1つは、私はYzmir - ickyに同意します。また、リンゴやオレンジを混ぜるような、リレーショナルデータベースの設計におけるOOの偽装を表しています。 OOプログラミングのバックグラウンドを持つ人（ME ...を含む）が「COmment Object」とそのプロパティを想像するのは簡単ですが、DB Designについて少し考えてみてください。例1のTablenamesは、それらが表すエンティティとそれらの間の関係（多対多の参照表）の両方で実際に起こっていることを明確に示しています。彼らはまた、 "正常な"フォームへのはるかに良い順守を表しています。

RBDMSは、エンティティとその関係を表現するものであり、必ずしもOOの原則と必ずしも一致しません。さらに、正規化のルールはオプション＃1に有利である。

オプション1は、より強力なRDBデザインを表し、管理が容易で、拡張が容易で、おそらくより高速に動作します。