Anti-modèle ?
Dans le cas courant, la deuxième table est anti-pattern dans le cadre de la conception de bases de données. Et, encore plus, il a un nom spécifique :Entity-Attribute-Value (EAV). Il y a des cas où l'utilisation de cette conception est justifiée, mais ce sont des cas rares - et même là, cela peut être évité.
Pourquoi l'EAV est mauvais
Prise en charge de l'intégrité des données
Malgré le fait qu'une telle structure semble être plus "flexible" ou "avancée", cette conception a des faiblesses.
- Impossible de rendre les attributs obligatoires . Vous ne pouvez pas rendre certains attributs obligatoires, car l'attribut est maintenant stocké sous forme de ligne - et le seul signe que l'attribut n'est pas défini - est que la ligne correspondante est absente de la table. SQL ne vous permettra pas de construire une telle contrainte nativement - vous devrez donc vérifier cela dans l'application - et, oui, interroger votre table à chaque fois
- Mélange de types de données . Vous ne pourrez pas utiliser les types de données standard SQL. Parce que votre colonne de valeur doit être un "super-type" pour toutes les valeurs stockées dans celle-ci. Cela signifie - vous devrez en général stocker toutes les données sous forme de chaînes brutes . Ensuite, vous verrez à quel point il est pénible de travailler avec des dates comme avec des chaînes, en castant les types de données à chaque fois, en vérifiant l'intégrité des données, etc.
- Impossible de faire respecter l'intégrité référentielle . Dans une situation normale, vous pouvez utiliser une clé étrangère pour restreindre vos valeurs à celles qui sont définies dans la table parent. Mais pas dans ce cas - c'est parce que l'intégrité référentielle est appliquée à chaque ligne de la table, mais pas pour les valeurs de ligne. Donc - vous perdrez cet avantage - et c'est l'un des fondamentaux en relation DB
- Impossible de définir des noms d'attributs . Cela signifie que vous ne pouvez pas restreindre correctement le nom de l'attribut au niveau de la base de données. Par exemple, vous écrirez
"customer_name"comme nom d'attribut dans le premier cas - et un autre développeur l'oubliera et utilisera"name_of_customer". Et... c'est bon, DB passera ça et vous finirez avec des heures passées à déboguer ce cas.
Reconstruction de ligne
De plus, la reconstruction des rangées sera affreuse dans le cas courant. Si vous avez, par exemple, 5 attributs - ce sera 5 self-table JOIN -s. Dommage pour un cas aussi simple - à première vue -. Donc, je ne veux même pas imaginer comment vous allez gérer 20 attributs.
Cela peut-il être justifié ?
Mon point est - non. Dans RDBMS, il y aura toujours un moyen d'éviter cela. C'est horrible. Et si EAV est destiné à être utilisé, alors le meilleur choix peut être non relationnel bases de données.
