Est-il raisonnable de diviser les données en différentes tables, en fonction d'une valeur de colonne?

Question

Si j'ai une grande table avec une colonne qui a une plage de valeurs plutôt limitée (par exemple < 100), est-il raisonnable de diviser cette table en plusieurs tables avec des noms liés à cette valeur de colonne?

Par ex une table comme avec des colonnes:

 
table "TimeStamps": [Id] [DeviceId] [MessageCounter] [SomeData]

où [DeviceId] est la colonne « portée limitée » seraient séparés en plusieurs tables différentes:

 
table "TimeStamps1": [Id] [MessageCounter] [SomeData] 
table "TimeStamps2": [Id] [MessageCounter] [SomeData] 
... 
table "TimeStampsN": [Id] [MessageCounter] [SomeData] 

Le problème que je rencontre avec ma table originale est que trouver un La plus grande valeur de MessageCounter pour certaines valeurs DeviceId prend beaucoup de temps à s'exécuter (voir this post).

Si les tables sont séparées, la recherche d'un nombre de colonnes maximal doit être une opération O (1).

[Modifier]

Juste trébuché sur ce, je pensais le mettre à jour. Avec une configuration correcte des index et des tâches de réorganisation d'index planifiées, j'ai pu obtenir de bonnes performances avec la forme normalisée. Je recommande d'essayer l'outil SSMS Database Engine Tuning Advisor pour chaque requête de goulot d'étranglement, il a été d'une grande aide (pour quelqu'un qui est le travail principal n'est pas la conception de base de données).

Answer 1

Alors que vous pourriez le faire comme une optimisation des performances de dernier recours, je déconseille. Principalement parce que cela rend très difficile l'adaptation de nouveaux DeviceID.

De toute façon, cela ne devrait pas être nécessaire. S'il existe un index pour DeviceID, le SGBD devrait pouvoir filtrer dessus très rapidement. Voilà ce qu'est un SGBD, après tout ...

Answer 2

Voici à quoi sert une base de données distribuée. Les serveurs partagent une table dans la même base de données basée sur une colonne. Vous indiquez aux serveurs comment distribuer la table en fonction des plages de valeurs de colonne. Une fois que cela est mis en place, vous interrogez simplement la table et ne sont pas concernés par le serveur sur lequel résident les données.

Answer 3

Je crains que cette approche ne contribue beaucoup à la complexité de toute application qui doit accéder à ces données. Une approche alternative, qui vous apporte tous les avantages que vous pourriez obtenir en plaçant chaque périphérique dans une table distincte tout en conservant tous les périphériques dans la même table, serait de partitionner la table sur DeviceID. Je vous suggère d'étudier le partitionnement des tables pour voir si cela correspond à vos besoins.

Partagez et appréciez.

Answer 4

Avez-vous considéré le partitionnement de base de données? C'est la solution cuite pour le type de problème que vous avez décrit. Voir: Partitioned Tables and Indexes in SQL Server 2005