アンチパターン？
一般的なケースでは、2番目のテーブルはアンチパターンです データベース設計のコンテキストで。さらに、特定の名前があります： Entity-Attribute-Value （EAV）。この設計を使用することが正当化される場合もありますが、それはまれなケースであり、それでも回避できます。
EAVが悪い理由
データ整合性のサポート
そのような構造はより「柔軟」または「高度」であるように見えるという事実にもかかわらず、この設計には弱点があります。
- 必須の属性を作成できません 。属性が行として格納されるようになり、属性が設定されていないことを示す唯一の兆候は、対応する行がテーブルにないことであるため、一部の属性を必須にすることはできません。 SQLでは、このような制約をネイティブに構築することはできません。したがって、アプリケーションでそれを確認する必要があります。そうです、毎回テーブルをクエリします
- データ型の混合 。 SQL標準のデータ型を使用することはできません。値列は、格納されているすべての値の「スーパータイプ」である必要があるためです。つまり、通常、すべてのデータを生の文字列として保存する必要があります。 。次に、文字列のように日付を操作したり、毎回データ型をキャストしたり、データの整合性をチェックしたりするのがどれほど面倒かがわかります。
- 参照の不誠実さを強制することはできません 。通常の状況では、外部キーを使用して、親テーブルで定義されている値によって値を制限できます。ただし、この場合はそうではありません。これは、参照整合性がテーブルの各行に適用されますが、行の値には適用されないためです。つまり、この利点は失われます。これは基本的なの1つです。 DBとの関係
- 属性名を設定できません 。つまり、DBレベルで属性名を適切に制限することはできません。たとえば、
"customer_name"と記述します。 最初のケースでは属性名として-そして別の開発者はそれを忘れて"name_of_customer"を使用します 。そして..それは大丈夫です、DBはそれを通過し、あなたはこのケースのデバッグに費やされた時間で終わります。
行の再構築
さらに、一般的なケースでは、行の再構築はひどいものになります。たとえば、5つの属性がある場合、これは5つのセルフテーブルJOINになります。 -s。そのような単純な-一見-ケースにはあまりにも悪い。ですから、20の属性をどのように維持するか想像すらしたくありません。
正当化できますか？
私のポイントは-いいえ。 RDBMSには、これを回避する方法が常にあります。ひどいです。また、EAVを使用する場合は、非リレーショナルが最適です。 データベース。