79
4.2 Partitionnement
lance une requête SELECT sur cette table au lieu de la table originelle. Mauvaise solution. La bonne réponse est : créez une vue, qui agrège les différentes tables par des
UNION ALL, et effectuez la requête sur cette vue :
CREATE VIEW Sales.vSalesOrderHeaderWithArchives
AS
SELECT
SalesOrderID, RevisionNumber, OrderDate, DueDate,
ShipDate, 0 as Source
FROM Sales.SalesOrderHeader
UNION ALL
SELECT
SalesOrderID, RevisionNumber, OrderDate, DueDate,
ShipDate, 2002 as Source
FROM Sales.SalesOrderHeader_Archive2002
Ici, pour déterminer dans nos requêtes de quelle table source provient chaque
ligne, nous ajoutons une colonne générée dans la vue.
Vous pouvez ensuite modifier votre requête pour effectuer la recherche sur cette
vue, ou prévoir deux types de recherche : une recherche sur la table originelle, et une
recherche sur toute l’étendue des données, en prévenant vos utilisateurs que la
recherche simple est plus rapide, mais ne comporte que des valeurs récentes.
La recherche simple sera-t-elle plus rapide ? Pas forcément. Si nous lui en donnons les moyens, l’optimiseur de SQL Server est capable de savoir si la requête que
nous lançons sur cette vue concerne bien toutes les tables, ou si l’accès à une des
tables suffit. Comment cela ? En plaçant une contrainte CHECK sur la structure des
tables sous-jacentes.
Pour illustrer la différence que va amener cet ajout, commençons par analyser les
tables affectées par cet ordre SQL :
SET STATISTICS IO ON
GO
SELECT *
FROM Sales.vSalesOrderHeaderWithArchives
WHERE OrderDate BETWEEN '20020301' AND '20020401';
Nous voulons les commandes passées en mars 2002...
Résultat des statistiques IO :
(305 row(s) affected)
Table 'SalesOrderHeader_Archive2002'. Scan count 1, logical reads 18...
Table 'SalesOrderHeader'. Scan count 1, logical reads 700...
Donc, 18 pages lues pour SalesOrderHeader_Archive2002, 700 pages lues pour
SalesOrderHeader.
Nous avons créé la table Sales.SalesOrderHeader_Archive2002 pour qu’elle ne
contienne que les lignes dont l’OrderDate est compris dans l’année 2002. La table
Sales.SalesOrderHeader ne contient donc plus que des lignes dont l’OrderDate est
différent de 2002. Exprimons cela en contraintes CHECK sur la colonne OrderDate :
ALTER TABLE Sales.SalesOrderHeader
4.2 Partitionnement
lance une requête SELECT sur cette table au lieu de la table originelle. Mauvaise solution. La bonne réponse est : créez une vue, qui agrège les différentes tables par des
UNION ALL, et effectuez la requête sur cette vue :
CREATE VIEW Sales.vSalesOrderHeaderWithArchives
AS
SELECT
SalesOrderID, RevisionNumber, OrderDate, DueDate,
ShipDate, 0 as Source
FROM Sales.SalesOrderHeader
UNION ALL
SELECT
SalesOrderID, RevisionNumber, OrderDate, DueDate,
ShipDate, 2002 as Source
FROM Sales.SalesOrderHeader_Archive2002
Ici, pour déterminer dans nos requêtes de quelle table source provient chaque
ligne, nous ajoutons une colonne générée dans la vue.
Vous pouvez ensuite modifier votre requête pour effectuer la recherche sur cette
vue, ou prévoir deux types de recherche : une recherche sur la table originelle, et une
recherche sur toute l’étendue des données, en prévenant vos utilisateurs que la
recherche simple est plus rapide, mais ne comporte que des valeurs récentes.
La recherche simple sera-t-elle plus rapide ? Pas forcément. Si nous lui en donnons les moyens, l’optimiseur de SQL Server est capable de savoir si la requête que
nous lançons sur cette vue concerne bien toutes les tables, ou si l’accès à une des
tables suffit. Comment cela ? En plaçant une contrainte CHECK sur la structure des
tables sous-jacentes.
Pour illustrer la différence que va amener cet ajout, commençons par analyser les
tables affectées par cet ordre SQL :
SET STATISTICS IO ON
GO
SELECT *
FROM Sales.vSalesOrderHeaderWithArchives
WHERE OrderDate BETWEEN '20020301' AND '20020401';
Nous voulons les commandes passées en mars 2002...
Résultat des statistiques IO :
(305 row(s) affected)
Table 'SalesOrderHeader_Archive2002'. Scan count 1, logical reads 18...
Table 'SalesOrderHeader'. Scan count 1, logical reads 700...
Donc, 18 pages lues pour SalesOrderHeader_Archive2002, 700 pages lues pour
SalesOrderHeader.
Nous avons créé la table Sales.SalesOrderHeader_Archive2002 pour qu’elle ne
contienne que les lignes dont l’OrderDate est compris dans l’année 2002. La table
Sales.SalesOrderHeader ne contient donc plus que des lignes dont l’OrderDate est
différent de 2002. Exprimons cela en contraintes CHECK sur la colonne OrderDate :
ALTER TABLE Sales.SalesOrderHeader