La meilleure façon de concevoir un tableau de données pour un nombre inconnu de colonnes?

Question

J'essaye de construire une structure de table de données qui supportera mieux les critères suivants:

1) Je ne sais pas combien de colonnes la table doit avoir.

• Je pourrais avoir besoin de 6 colonnes dans certains cas, ou 10 dans d'autres. Je ne m'attends pas à ce que cette table ait besoin de 20 colonnes ou plus, mais je ne peux pas non plus garantir que cela ne sera jamais nécessaire.

2) Je dois prendre en compte l'espace de stockage et la vitesse de reporting.

• Cette table doit stocker des millions d'enregistrements et les rapports seront exécutés sur cette table. Je sais qu'il est difficile de faire pivoter des tableaux hautement normalisés du point de vue des rapports. Je veux donc procéder à la normalisation de la déclaration. Mais, je ne sais pas si le simple fait de ne pas utiliser un grand nombre de colonnes afin d'éviter une normalisation est une bonne idée car je finirai probablement avec beaucoup de NULLS dans la plupart des colonnes à la fin de la table, et ceux-ci (je pense) prennent tous une certaine quantité d'espace de stockage.

3) Si je dois choisir entre l'espace de stockage et les performances de rapport, je serai du côté des performances. Je ne suis pas un expert en intelligence d'affaires, et je ne suis pas un gourou T-SQL (je vais utiliser SQL Server), et donc je suis sûr qu'il y a des points précis ici que j'ai simplement oubliés. Ainsi, je me tourne à nouveau vers la brillante communauté SO pour obtenir des conseils, et avoir un peu de sens dans mon crâne épais.

Comment concevez-vous la table dans ces circonstances? Quels sont les détails qui me manquent et doivent encore être pris en compte?

Answer 1

La plupart des conceptions de table générique pour lesquelles les valeurs de colonne sont décidées en fonction des paramètres utilisateur conduiront à des performances médiocres, car toutes les requêtes seront dynamiques.

La chose raisonnable à faire serait de fournir une estimation du nombre de colonnes et de laisser les valeurs inutilisées être nulles initialement. Pouvez-vous donner un exemple de ce à quoi sert votre histoire? Un des exemples qui soulève cette question est quand vous avez une table de produit et certains produits ont seulement 5 attributs et certains ont 50. Comme je l'ai dit ci-dessus, vous feriez mieux de créer la table avec 50 colonnes (si vous voulez tableau des produits) et ayant les autres colonnes comme nul si nécessaire.

Les outils de création de rapports et la plupart des SGBDR gèrent les valeurs nulles lors de l'agrégation et du regroupement.

Answer 2

Les colonnes du tableau représentent les spécifications de l'entité à stocker. Dire que vous ne savez pas combien de colonnes seront stockées signifie que vous ne connaissez pas la spécification de la substance à stocker. Autrement dit, vous voulez construire un système sans savoir ce qu'il va stocker. Les bases de données relationnelles ne sont fondamentalement pas conçues pour gérer ce et fonctionnent bien et peuvent être maintenues. Pour bien fonctionner et être maintenable, les bases de données relationnelles reposent sur le temps nécessaire pour déterminer la nature de l'entité à stocker et ses attributs, puis construire le schéma approprié. Ainsi, la solution la plus performante et la plus facile à maintenir utilisant une base de données relationnelle consiste à construire le schéma tel qu'il est requis, ce qui signifie rassembler les spécifications sur ce qui doit être stocké selon les besoins.Cela dit, il existe des alternatives aux bases de données relationnelles telles que les bases de données «nosql» qui pourraient mieux répondre aux besoins d'une conception uber-élastique qu'une base de données relationnelle. Des exemples de ceux-ci comprennent MongoDB et CouchDB.