Utilisation des vues partitionnées

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 partitionnement. Une vue qui utilise UNION ALL pour combiner les sélections de toutes les tables membres en un seul jeu de résultats est alors définie. Lorsque les instructions SELECT faisant référence à la vue spécifient une condition 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.

Notes

La méthode la plus adaptée pour le partitionnement des données locales d'un serveur est l'utilisation de 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 définie 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 correspond au mois de mai 1998. Cette vérification s'effectue à l'aide 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 jeu 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 la condition de recherche de cette instruction SELECT fait 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 obtenir 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 à la condition 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 ; par ailleurs, il ne peut pas ignorer d'effectuer des recherches dans les tables qui participent à 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 de manière indépendante. 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.

Notes

L'importation en bloc dans une vue partitionnée n'est pas prise en charge par la commande bcp ni par les instructions BULK INSERT et INSERT ... SELECT * FROM OPENROWSET(BULK...). Toutefois, vous pouvez insérer plusieurs lignes dans une vue partitionnée en utilisant une instruction INSERT.