アプリケーションの論理データ モデルを考え出すように依頼されました。すべてのエンティティを特定し、ERD を使用して文書化しました。今、同僚が私が同意しないいくつかの変更を提案しており、問題に対する最善の解決策を考え出すことができるように、私と彼のアプローチに賛成する理由と反対する理由が必要です.
したがって、基本的にはこれに関する議論です: 私はこのようなエンティティを持っています:
The_Entity
そして、私の同僚はやることを提案しています
The_Entity
属性
したがって、基本的に属性もエンティティとしてモデル化します。
私のアプローチは意味的にはより理にかなっていると思いますが、より静的でもあります (実装では、属性を追加するには、テーブルに列を追加する必要があります)。これについてどう思いますか？
同僚が提唱しているのは「エンティティ属性値」またはEAVと呼ばれ、広くアンチパターンと見なされます。（グーグルは「EAV悪」を探し回っています。多くの例があります。）同僚が提案しているように弾薬を使用しない理由が必要な場合は、問題なく見つけることができます。
そうは言っても、SOとDBA.SEに関する私の回答を見ると、EAVの悪い点が当てはまらない特定の状況では、私がEAVのまれな支持者であることがわかります。それでも、特定のモデルがこれらの例外的な条件を満たしているかどうかはわかりませんので、EAVを回避するのはかなり安全だと思います。
すでに与えられた答えに同意します。
EAV に対する最も明白なケースは、言及した属性を含むビジネス ルールがある場合です。あなたの例では、「属性 1 と属性 2 の両方を ... 文字より長くすることはできません」と言います。
単一の 3 列テーブルを使用して例を実装する場合、そのビジネス ルールの実装は、そのテーブルに単一の CHECK 制約を定義するのと同じくらい単純で簡単です。ルールは単純明快であり、後で設計を読む他の人がデコードするためにも使用でき、実行時に制約をチェックするのはスウッシュのようになります。
EAV アプローチを使用して例を実装する場合、同じビジネス ルールを宣言的に実装することはできません。そのため、(かなりの量の) 余分なコードが必要になり、後で設計を読む人にとっては解読が難しくなります。特にトランザクションのシリアライゼーションの分野では、間違いを犯す可能性が高くなり、実行時にシステムを足のない犬のように実行させるパフォーマンスの悪夢になる可能性があります。
また、属性の値が整数、日付、浮動小数点数、ブール値、または DBMS が提供するその他の型であるかどうか、友人が設計にどのように属性を含めるつもりなのかを尋ねることもできます。(彼は単一のテーブルに固執することはできず、読み取り時に任意の数値のストリングを解除し、書き込み時に任意の数値をストリングに変換しなければならないというパフォーマンス上の問題が発生します。これは CPU ホグの悪夢です。)
あなたの友人が「発見」したのは、実際には DBMS 自体がユーザーのデータベースの構造を文書化するために使用する設計です。DBMS カタログはその構造を何十年も前から知っていたので (もちろん、「V」の部分を除いて、カタログは EA、いわば V のない EAV です)、まったく「新しい」アイデアではありません。
そうです、彼が彼の設計では、データベースの構造を適応させる方がはるかに簡単であると主張するとき、彼はある意味で正しいです. しかし、その「柔軟性の向上」の実際の付加価値 (通常、EAV 支持者が示唆するものよりも低い) も考慮すると、柔軟性の向上に対して支払う代償は、ほとんどの場合、法外に高くなります。
EAV アプローチが受け入れられる典型的なケースは、アンケートの処理です。アンケートが実際には 99.99% 安定しておらず (時間の経過とともに大幅に拡張される可能性があります)、「記入方法」に適用される「ルール」があまりない場合 (質問 7 への回答が「はい」の場合、質問 8 に回答する必要があります) であり、アンケートへの回答は通常、「組み合わせ」よりも「単独」で検査されるため、EAV の欠点のほとんどは当てはまらず、有効に検討することができます。