Je crée une base de données dans laquelle il y aura environ 30 tables, chaque table contenant des dizaines de millions de lignes et chaque table contenant une seule colonne importante et une colonne de clé primaire / étrangère afin de maximiser l'efficacité des requêtes face à des charges lourdes mises à jour et insertions et faire un usage intensif des index cluster. Deux des tableaux contiendront des données textuelles de longueur variable, l'un d'entre eux contenant des centaines de millions de lignes, mais le reste ne contiendra que des données numériques.
Comme je veux vraiment extraire chaque dernière goutte de performances du matériel dont je dispose (environ 64 Go de RAM, un SSD très rapide et 16 cœurs), je pensais autoriser chaque table à avoir son propre fichier afin que, peu importe si Je me joins à 2, 3, 4, 5 tables ou plus, chaque table sera toujours lue en utilisant un thread séparé et la structure de chaque fichier sera étroitement alignée avec le contenu de la table, ce qui, espérons-le, minimisera la fragmentation et la rendra plus rapide pour SQL Server à ajouter au contenu d'une table donnée.
Une mise en garde, je suis bloqué sur SQL Server 2008 R2 Web Edition . Ce qui signifie que je ne peux pas utiliser le partitionnement horizontal automatique, ce qui exclut cela comme une amélioration des performances.
L'utilisation d'un fichier par table maximisera-t-elle réellement les performances, ou suis-je en train de négliger les caractéristiques du moteur SQL Server intégré qui rendraient cela si redondant?
Deuxièmement, si l'utilisation d'un fichier par table est avantageuse, pourquoi ne create tableme donne-t-il que l'option d'allouer la table à un groupe de fichiers et non à un fichier logique spécifique? Cela m'obligerait à créer un groupe de fichiers distinct pour chaque fichier de mon scénario, ce qui me suggère que peut-être SQL Server n'envisage pas les avantages dont je suppose qu'ils découleraient de ce que je propose.
