Création des tables partitionnées.

vous divisez. Chaque table contiendra une tranche de la table originale. Le point clé de la création des tables partitionnées est que chaque table contient une colonne appelée colonne de partitionnement, et la valeur dans cette colonne détermine dans laquelle des tables partitionnées on peut insérer n’importe quelle ligne. Le critère de partition, que l’on implémente comme une contrainte de type CHECK, définit le sous-ensemble que chaque partition va accueillir. Les contraintes de type CHECK sur chacune des tables doivent être mutuellement exclusives. Chaque ligne que l’on souhaite insérer ne doit satisfaire qu’à  une de ces contraintes, comme nous allons le démontrer.
Nous utiliserons par la suite une instruction UNION pour combiner ces tables dans une vue modifiable. Comme nous l’avons dit, les vues basées sur des instructions UNION sont modifiables sous certaines conditions. Si vous voulez optimiser l’efficacité des requêtes, exploitez les nouvelles possibilités de SQL Server 2000 en rendant possible les mises à  jour directement sur la vue, ensuite vous devez vous assurer que les conditions suivantes sont remplies pour chacune des tables :

· La colonne de partitionnement doit faire partie de la clé primaire des tables sous-jacentes, ne pas autoriser NULL et ne peut être une colonne issue d’un calcul.
· La contrainte CHECK définie sur la colonne de partitionnement définissant le critère de partition ne peut contenir que les séparateurs suivants : BETWEEN, AND, OR, <, <=, >, =>, =.
· Les tables ne peuvent comporter de colonnes identifiants ou horodatage, et aucune des colonnes ne peut avoir de contrainte DEFAULT, quelle que soit la table.

Deux points importants : comment choisir sa colonne de partitionnement, et quelle quantité d’enregistrements doit accueillir chacune des partitions ? Le critère de partitionnement le plus efficace est celui qui renvoie à  une plage de valeurs dans chacune des tables partitionnées ayant le plus de chance d’être consultées localement par les utilisateurs, et dont résulterait une distribution de lignes la plus uniforme possible (des noms de clients, des numéros de pièce, ou une région géographique par exemple). Ce montage permet de laisser le traitement de la plupart des requêtes sur le serveur local, et minimise les besoins en traitements distribués.
Maintenant que nous connaissons les exigences inhérentes aux tables, nous allons pouvoir les créer. Dans notre exemple, nous verrons comment créer des tables similaires aux tables Customers et Orders de la base de données Northwind. Nous allons distribuer les lignes entre les tables en fonction de la première lettre de l’identifiant Client (Customer). Les lettres A à  F iront dans la première table, G à  P dans la seconde, et Q à  Z dans la troisième. Les exemples de code qui suivent s’exécutent dans une base de données appelée testdb, que nous avons créée sur chacun des serveurs. Le listing 4 montre le script qui crée les premières tables partitionnées sur le serveur Shire\Shiloh (noeud 1).
Quelques points importants à  noter à  propos de ce script. Il y a une contrainte CHECK sur la colonne customerid, qui fait partie de la clé primaire dans les tables CustomersAF et « OrdersAF. Cette contrainte limite l’accès de la table aux clients dont les identifiants sont dans la plage AAAAA à  FZZZZ. Cette contrainte sera utilisée pour optimiser les requêtes et modifier les données. Si on veut partitionner la table Orders en utilisant l’identifiant client, il faut inclure la colonne en question dans la clé primaire. Partitionner la table Customer originale en utilisant l’identifiant client est évident, mais pourquoi utiliser le même critère pour la table Orders ? Nous aborderons le critère de partitionnement dans un prochain article, lorsque nous montrerons comment lancer une requête sur une vue partitionnée. Notez qu’afin de garantir l’unicité des lignes, l’identifiant client doit faire partie de la clé primaire. Toutefois, afin de gérer efficacement les données, il doit également être une des clés de la table Orders, pour pourvoir la partitionner en l’utilisant.
Comme pour le noeud 1, créer ensuite les tables partitionnées sur les serveurs Hobbiton\Shiloh (noeud 2), avec des identifiants Customers compris entre GAAAA et PZZZZ, comme sur le listing 5. Enfin, créer les tables partitionnées sur les serveurs Rivendell\Shiloh (noeud 3), avec des identifiants Customers compris entre QAAAA et ZZZZZ, comme le montre le listing 6.