Utilisation des vues partitionnées

Mis à jour : 17 juillet 2006

Les vues partitionnées permettent de fractionner une grande table en tables membres plus petites. Les données sont partitionnées entre les tables membres en fonction des plages de valeurs des données de l'une des colonnes. Les plages de données de chaque table membre sont définies dans une contrainte CHECK spécifiée sur la colonne de partition. Une vue qui utilise UNION ALL pour combiner les sélections de toutes les tables membres en un seul ensemble de résultats est alors définie. Lorsque les instructions SELECT désignant la vue spécifient un critère de recherche sur la colonne de partition, l'optimiseur de requête utilise les définitions de la contrainte CHECK pour déterminer la table membre qui contient les lignes.

Remarque :
La méthode la plus adaptée pour le partitionnement de données locales vers un serveur reste à travers des tables partitionnées. Pour plus d'informations, consultez Tables et index partitionnés.

Par exemple, supposons que la table des ventes 1998 ait été partitionnée en douze tables membres, une pour chaque mois. Chaque table membre est assortie d'une contrainte portant sur la colonne OrderMonth :

CREATE TABLE May1998sales
   (OrderID      INT,
   CustomerID      INT      NOT NULL,
   OrderDate      DATETIME      NULL
      CHECK (DATEPART(yy, OrderDate) = 1998),
   OrderMonth      INT
      CHECK (OrderMonth = 5),
   DeliveryDate      DATETIME      NULL
      CHECK(DATEPART(mm, DeliveryDate) = 5)
   CONSTRAINT OrderIDMonth PRIMARY KEY(OrderID, OrderMonth)
   )

L'application qui remplit la table May1998sales doit s'assurer que toutes les lignes de la colonne OrderMonth contiennent le chiffre 5 et que la date de commande appartient au mois de mai 1998. Cette vérification s'effectue par le biais des contraintes définies sur la table.

Une vue qui utilise UNION ALL pour sélectionner les données des douze tables membres sous la forme d'un seul ensemble de résultats est alors définie :

CREATE VIEW Year1998Sales
AS
SELECT * FROM Jan1998Sales
UNION ALL
SELECT * FROM Feb1998Sales
UNION ALL
SELECT * FROM Mar1998Sales
UNION ALL
SELECT * FROM Apr1998Sales
UNION ALL
SELECT * FROM May1998Sales
UNION ALL
SELECT * FROM Jun1998Sales
UNION ALL
SELECT * FROM Jul1998Sales
UNION ALL
SELECT * FROM Aug1998Sales
UNION ALL
SELECT * FROM Sep1998Sales
UNION ALL
SELECT * FROM Oct1998Sales
UNION ALL
SELECT * FROM Nov1998Sales
UNION ALL
SELECT * FROM Dec1998Sales

Par exemple, l'instruction SELECT suivante recherche des informations concernant certains mois.

SELECT *
FROM Year1998Sales
WHERE OrderMonth IN (5,6) AND CustomerID = 64892

L'optimiseur de requête SQL Server reconnaît que les critères de sélection de cette instruction SELECT font uniquement référence aux lignes des tables May1998Sales et Jun1998Sales. Par conséquent, il limite ses recherches à ces tables.

Pour qu'il soit possible d'effectuer des mises à jour sur une vue partitionnée, la colonne de partitionnement doit faire partie de la clé primaire de la table de base. Si une vue ne peut pas être mise à jour, vous pouvez créer un déclencheur INSTEAD OF sur la vue qui autorise les mises à jour. Vous devez concevoir la gestion des erreurs dans le déclencheur pour vous assurer qu'aucune ligne n'est insérée deux fois. Pour visualiser un exemple de déclencheur INSTEAD OF conçu sur une vue, consultez Conception de déclencheurs INSTEAD OF.

Les contraintes CHECK ne sont pas nécessaires pour que la vue partitionnée retourne des résultats corrects. Cependant, si les contraintes CHECK n'ont pas été définies, l'optimiseur de requête doit étendre sa recherche à toutes les tables, et pas seulement à celles qui répondent aux critères de recherche dans la colonne de partitionnement. Sans les contraintes CHECK, la vue se comporte comme toute autre vue contenant l'instruction UNION ALL. L'optimiseur de requête ne peut faire aucune hypothèse sur les valeurs stockées dans les différentes tables, et il doit effectuer des recherches dans l'ensemble des tables associées à la définition de la vue.

Si toutes les tables membres référencées par une vue partitionnée se trouvent sur le même serveur, la vue est une vue partitionnée locale. Si les tables membres se trouvent sur plusieurs serveurs, la vue est une vue partitionnée distribuée. Les vues partitionnées distribuées peuvent être employées pour répartir la charge de traitement de la base de données d'un système dans un groupe de serveurs. Pour plus d'informations, consultez Serveurs de bases de données fédérés.

Les vues partitionnées simplifient la maintenance des tables membres individuellement. Par exemple, vous pouvez effectuer les opérations suivantes à la fin d'une période :

• vous pouvez mettre à jour la définition de la vue partitionnée contenant les résultats actuels, en ajoutant la période la plus récente et en supprimant la plus ancienne ;
• vous pouvez mettre à jour la définition de la vue partitionnée contenant les résultats antérieurs, en ajoutant la période qui vient d'être supprimée de la vue des résultats actuels. La vue des résultats antérieurs peut également être mise à jour en supprimant et en archivant la période la plus ancienne qu'elle couvre ;

lorsque vous insérez des données dans les vues partitionnées, vous pouvez utiliser la procédure stockée système sp_executesql pour créer des instructions INSERT avec des plans d'exécution qui sont susceptibles d'être réemployés dans les systèmes où les utilisateurs simultanés sont très nombreux.

Voir aussi

Concepts

Création de vues partitionnées
Création de vues partitionnées de données distribuées
Conception d'applications pour utiliser des serveurs de bases de données fédérés

Autres ressources

ALTER VIEW (Transact-SQL)
SELECT (Transact-SQL)
CREATE VIEW (Transact-SQL)
sp_executesql (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications