Colonnes dynamiques SQL Server Problème

Question

J'utilise une table GadgetData pour stocker les propriétés des gadgets dans mon application. Les gadgets sont en quelque sorte des contrôles personnalisés qui ont 80% des propriétés communes comme la hauteur, la largeur, la couleur, le type, etc. Il existe un ensemble de propriétés par type de gadget qui leur est propre. Toutes ces données doivent être stockées dans la base de données. Actuellement, je stocke uniquement les propriétés communes. Quelle approche de conception devrais-je utiliser pour stocker ce genre de données où les colonnes sont dynamiques.

1. Créez une table avec des propriétés communes sous la forme Colonnes et ajoutez une colonne supplémentaire de type Texte pour stocker toutes les propriétés uniques de chaque type de gadget au format XML.
2. Créez une table avec toutes les colonnes possibles dans tous les types de gadget.
3. Créez un tableau distinct pour chaque type de gadget.
4. Une autre meilleure façon que vous recommandez?

(Note: Le nombre de types de gadget pourrait croître même au-delà de 100 et)

Answer 1

L'option 3 est une option très normalisée, mais elle reviendra et vous mordra si vous devez interroger plusieurs types - chaque SELECT aura une autre jointure si un nouveau type est ajouté. Un cauchemar d'entretien.

L'option 2 (table clairsemée) aura beaucoup de valeurs NULL et prendra de l'espace supplémentaire. La définition de la table devra également être mise à jour si un autre type est ajouté dans le futur. Pas si mal mais toujours douloureux. J'utilise l'option 1 en production (en utilisant un type xml au lieu de text). Cela me permet de sérialiser n'importe quel type dérivé de mon type commun, en extrayant les propriétés communes et en laissant les uniques dans la colonne XmlProperties. Cela peut être fait dans l'application ou dans la base de données (par exemple, une procédure stockée).

Answer 2

Selon la façon dont différents les « gadgets » sont je ne voudrais pas l'option 2 il y aurait beaucoup de nulls flottant autour , ce qui pourrait être mauvais si vous aviez une colonne qui était obligatoire pour un gadget mais pas même utilisé pour un autre.

Je ne choisirais l'option 3 que si le nombre de gadgets change peu, car cela nécessiterait de modifier la base de données à chaque fois. L'option non mentionnée est de stocker les gadgets avec une table enfant qui contient les valeurs uniques des gadgets. Mais cela nécessiterait une bonne quantité de travail pour retourner les détails des gadgets, ou plusieurs appels de base de données. En laissant l'option 1, sauf que j'utiliserais le type XML des serveurs SQL au lieu du texte, vous pouvez utiliser XQuery dans vos procédures stockées.

Answer 3

Vos options:

1. bon.Pourrait même forcer schéma etc
2. Vous ne pouvez pas faire les colonne NOT NULL, vous perdrez une certaine intégrité des données, il
3. Tant que vous ne permettez pas à la recherche de plus d'un type de gadget, il est assez bon, mais l'option 1 est mieux
4. J'utiliser ORM

notes:

Si vous souhaitez garder votre base de données « relationnelle », mais pas peur d'utiliser des outils ORM, alors j'utiliser un . Dans ce cas, vous pouvez stocker les données (presque) comme vous le souhaitez, mais les gérer correctement tant que vous les mappez correctement. Voir:

• Single Table Inheritance
• Concrete Table Inheritance

Si vous avez besoin solution SQL uniquement, en fonction puis sur votre SGBDR, je ne serais probablement utiliser la colonne XML pour stocker toutes les données spécifiques à la type de gadget: vous pouvez avoir une validation, étendre facilement avec de nouveaux attributs. Ensuite, vous pouvez avoir tous dans un tableau, rechercher rapidement tous les attributs communs, et aussi facilement rechercher des attributs de type d'un gadget

Answer 4

Si tous les types de gadgets ont de nombreuses propriétés obligatoires communes qui peuvent être stockées dans une table et juste quelques propriétés optionnelles, vous feriez mieux d'utiliser la première approche: ainsi vous utiliserez le meilleur des schémas relationnels et facilitez votre vie avec XML. Et n'oubliez pas d'utiliser la collection de schémas XML qui lient la colonne XML: vous aurez des capacités d'indexation et de XQuery complètes.

Si les types de gadgets ont très descriptions différentes et seulement 1-3 colonnes communes parmi 5 ou plus ensemble de propriétés différentes, utilisez la 3ème approche.

---

Mais en ce qui concerne la situation des 100+ types de gadgets j'utiliser 1ère approche: il a une flexibilité soutenue avec de bonnes performances et la facilité de soutien et de développement.