実際に説明した設計（共通テーブルとサブタイプ固有のテーブル）は、クラステーブル継承 。
具体的なテーブル継承 サブタイプテーブルですべての共通属性が複製され、現在のようにスーパータイプテーブルはありません。
私はEAVに強く反対しています。これはSQLのアンチパターンだと思います。必要なテーブルが少ないため、エレガントなソリューションのように思えるかもしれませんが、後で多くの頭痛の種に備えることになります。あなたはいくつかの不利な点を特定しましたが、他にもたくさんあります。 IMHO、EAVは、絶対にしてはいけない場合にのみ適切に使用されます。 新しいサブタイプを導入するとき、またはサブタイプの数に制限がない場合（たとえば、ユーザーは新しい属性をアドホックに定義できます）、新しいテーブルを作成します。
多くのサブタイプがありますが、それでも数は限られているため、このプロジェクトを実行する場合は、クラステーブル継承を使用します。 。各サブタイプの行が少ない場合がありますが、少なくとも各サブタイプのすべての行が同じ列であることがある程度保証されているため、NOT NULLを使用できます。 必要に応じて、SQLデータ型を使用したり、参照整合性制約を使用したりできます。リレーショナルの観点からは、EAVよりも優れた設計です。
あなたが言及しなかったもう1つのオプションは、シリアル化されたLOB と呼ばれます。 。つまり、カスタム属性の半構造化コレクションのBLOB列を追加します。 XML、YAML、JSON、または独自のDSL を保存します その列に。 SQLを使用してそのBLOBから個々の属性を簡単に解析することはできません。BLOB全体をアプリケーションにフェッチして戻し、コードで個々の属性を抽出する必要があります。したがって、いくつかの点でそれはあまり便利ではありません。しかし、それがデータの使用法を満たしているのであれば、それは何も悪いことではありません。