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

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
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
