En fait, la conception que vous avez décrite (table commune plus tables spécifiques aux sous-types) s'appelle Class Table Inheritance .
Héritage de table concrète aurait tous les attributs communs dupliqués dans les tables de sous-types, et vous n'auriez pas de table de supertypes comme vous le faites maintenant.
Je suis fortement contre EAV. Je le considère comme un antimodèle SQL. Cela peut sembler être une solution élégante car elle nécessite moins de tables, mais vous vous préparez à beaucoup de maux de tête plus tard. Vous avez identifié quelques inconvénients, mais il y en a beaucoup d'autres. À mon humble avis, EAV n'est utilisé de manière appropriée que si vous ne devez absolument pas créez une nouvelle table lorsque vous introduisez un nouveau sous-type, ou si vous avez un nombre illimité de sous-types (par exemple, les utilisateurs peuvent définir de nouveaux attributs ad hoc).
Vous avez de nombreux sous-types, mais toujours un nombre fini d'entre eux, donc si je faisais ce projet, je m'en tiendrais à Class Table Héritage . Vous pouvez avoir quelques lignes de chaque sous-type, mais au moins vous avez une certaine assurance que toutes les lignes de chaque sous-type ont les mêmes colonnes, vous pouvez utiliser NOT NULL si vous en avez besoin, vous pouvez utiliser des types de données SQL, vous pouvez utiliser des contraintes d'intégrité référentielle, etc. D'un point de vue relationnel, c'est une meilleure conception que EAV.
Une autre option que vous n'avez pas mentionnée est appelée Serialized LOB . Autrement dit, ajoutez une colonne BLOB pour une collection semi-structurée d'attributs personnalisés. Stockez XML, YAML, JSON ou votre propre DSL dans cette colonne. Vous ne pourrez pas analyser facilement les attributs individuels de ce BLOB avec SQL, vous devrez récupérer le BLOB entier dans votre application et extraire les attributs individuels dans le code. Donc, à certains égards, c'est moins pratique. Mais si cela satisfait votre utilisation des données, il n'y a rien de mal à cela.
