Type de cellule dynamique de la table SQL

Question

Disons que j'ai un Product et un ProductType tableau.Je veux un tableau dans lequel je peux stocker des colonnes spéciales pour chaque type de produit.Les colonnes spéciales (attributs) peuvent être de n'importe quel type.

En ce moment, nous avons une table par ProductType appelé Product_%ProductTypeId% quelle est une solution que je n'aime vraiment pas - des suggestions ?

Mon idée était d'avoir une table ProductTypeColumns avec les colonnes :

Id | ProductTypeId | ColumnName | Value  | ColumnType

ce que je n'aime pas là-dedans, c'est que je perds la sécurité du type, colonne Value serait un type de chaîne, ce qui signifierait que je dois toujours convertir vers et depuis.

De plus, ce tableau sera utilisé pour générer des rapports.avoir des colonnes "dynamiques" peut être un problème.

Answer 1

C'est appelé VAE.
Vous pouvez trouver quelques questions sur EAV et SQL Server ici sur SO :

• EAV sur SQL Server
• Performances des grands systèmes EAV/à schéma ouvert sur SQL Server

C'est un sujet sur lequel beaucoup de personnes différentes auront des opinions différentes.
Certains diront qu'il faut s'en tenir à Product_%ProductTypeId% tables, et certains diront que votre ProductTypeColumns la table est la meilleure façon.

En gros, je suis dans le ProductTypeColumns camp.
Nous utilisons également quelque chose de similaire au travail :
Notre table contient des attributs pour les postes de commande (plus d'un million de postes de commande et plus de 250 millions d'attributs) et nous l'utilisons depuis près de dix ans maintenant.
Désavantages:pas de sécurité de type (comme vous l'avez déjà mentionné) et l'interrogation peut être un peu compliquée.

Mais pour nous, c'est la seule voie possible car nous avons plus de 1000 attributs, plus de 100 produits et chaque produit peut avoir 100 à 300 attributs.Avec des dimensions comme celles-ci, une table attributaire est la seule solution possible.
Mais ce n’est probablement pas la meilleure solution pour tout le monde et je ne sais pas si c’est la meilleure solution pour vous.

Si votre nombre de produits et d'attributs spéciaux n'est pas si important, vous pourrez peut-être vous en sortir avec votre première suggestion (Product_%ProductTypeId% les tables).
Ce serait certainement plus facile à interroger, mais ce n'est peut-être pas une option s'il y a trop de combinaisons possibles de produits et d'attributs.

Comme souvent, ça dépend.

Answer 2

Qu’en est-il de la hiérarchie des catégories (alias."héritage", "sous-type", "sous-classe") ?

Personnellement, j'opterais pour une solution de paire nom/valeur (décrite dans votre question) uniquement si les colonnes sont pas prédéterminé.

Si vous connaissez toutes les colonnes à l'avance et qu'il est peu probable qu'elles changent, alors implémentez une hiérarchie de catégories, mais non sans complications, préserverait la sécurité des types et permettrait de mieux appliquer l'intégrité déclarative par le SGBD (par ex.vous pouvez avoir une contrainte spécifique au produit (UNIQUE, FOREIGN KEY ou CHECK).