いいえ、これはリレーショナルデータベースの設計としては不適切です。これは、Entity-Attribute-Valueの例です。 設計。柔軟性はありますが、リレーショナルデータベースであるということの意味に関するほとんどのルールに違反しています。
柔軟なデータベースのソリューションとしてEAVの設計に取り掛かる前に、次のストーリーを読んでください。悪いCaRMa 。
具体的には、EAVの問題には次のようなものがあります。
- 特定のID_NUMにどの属性が存在するかは、クエリを実行しないとわかりません。
- NOTNULLに相当する属性を必須にすることはできません。
- データベース制約を使用することはできません。
- SQLデータ型は使用できません。
value列は長いVARCHARである必要があります。 - 特にMySQLでは、各VARCHARは独自のデータページに保存されるため、これは非常に無駄です。
EAVデザインを使用する場合、クエリも非常に複雑になります。オープンソースのeコマースプラットフォームであるMagentoはEAVを幅広く使用しており、多くのユーザーは、カスタムレポートが必要な場合、クエリを実行するのは非常に遅く、難しいと言っています。
リレーショナルにするには、それぞれの異なる属性を、独自の名前と適切なデータ型を使用して、独自の列に格納する必要があります。
プレゼンテーションでEAVについて詳しく書いています