Maintenant que nous avons mis en place les tables partitionnées, il faut les assembler, ce qui est certainement la partie la plus simple du processus. Il suffit de définir une vue qui assemble les lignes de chaque table en utilisant l'opérateur UNION ALL. Sur chaque serveur, on a une table
Création des vues partitionnées.

locale et deux tables distantes, et donc la vue semble légèrement différente pour chacun d’entre eux. On référence la table locale en utilisant son nom, et les tables distantes avec un nom en quatre parties (Node2.testdb.dbo.CustomersGP par exemple). Créons une vue partitionnée sur le serveur Shire\Shiloh (noeud 1), comme le montre le listing 7. Après avoir créé cette vue, les utilisateurs peuvent commencer à modifier ou lancer des requêtes s’ils sont connectés à Shire\Shiloh (noeud 1). La création de vues similaires sur les deux autres serveurs permet les mêmes modifications et requêtes sur les serveurs auxquels les utilisateurs sont connectés.
Comme pour le noeud 1, créer des vues sur le serveur Hobbiton\Shiloh (noeud 2), comme le montre le listing 8, ainsi que sur Rivendell\Shiloh (noeud 3, listing 9). Comme les tables partitionnées, les vues partitionnées doivent répondre à quelques conditions pour pouvoir être modifiables et utiliser les nouvelles capacités d’optimisation de SQL Server 2000 :
· La vue ne peut se rapporter à une table ou une colonne plus d’une fois.
· Chaque liste SELECT doit se rapporter à toutes les colonnes participant aux clé primaires des tables
· Les colonnes de même position ordinale sur la liste choisie, quelles que soient les instructions de sélection, doivent être exactement du même type, précision, échelle et séquence de tri. Et les colonnes de partitionnement doivent être dans la même position ordinale.
· Si une colonne existe dans la table de base, mais pas dans la liste choisie pour la vue, elle doit autoriser la valeur NULL.
Notez que les deux dernières exigences sont beaucoup plus strictes que n’importe laquelle de celles utilisées pour créer des vues locales non partitionnées. Les vues simples doivent avoir des types de données compatibles sur les positions correspondantes dans les listes choisies, mais elles n’ont pas à être exactement les mêmes. De plus, on peut insérer des données dans des vues simples, même si les colonnes de la table de base qui ne sont pas incluses dans la vue n’acceptent pas NULL, mais ont des valeurs par défaut. Si on insère des données dans une vue partitionnée distribuée, les colonnes ne peuvent avoir de valeurs par défaut.
Téléchargez cette ressource

Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.
Les articles les plus consultés
- Et si les clients n’avaient plus le choix ?
- Les 6 étapes vers un diagnostic réussi
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Cybersécurité Active Directory et les attaques de nouvelle génération
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
