La cerise sur le gâteau

logique similaire en raison de l’instruction
GROUP BY. Toutefois, dans le
schéma de base de données SuperSub,
vous pouvez désormais obtenir le
montant mensuel en additionnant la
colonne LeaseRate dans une table,
Items. De ce fait, vous pouvez omettre
la requête séparée et utiliser simplement
l’opérateur ROLLUP de la clause
GROUP BY. Utilisez l’opérateur ROLLUP
de SQL Server avec la clause
GROUP BY dans de telles situations,
pour fournir un total général.
Voyons la version finale de la procédure
stockée leasedetail, qu’illustre
le listing 3. Il y a beaucoup moins de
code que dans GetInvoiceDetails, mais
il faut aussi noter comment on peut
maintenant générer la totalité du rapport
au moyen d’une seule instruction
SELECT qui utilise l’opérateur ROLLUP,
au lieu d’unir des jeux de résultats multiples.
ROLLUP produit davantage d’informations
résumées que nécessaire,
donc vous pouvez utiliser la clause HAVING
pour éliminer les lignes superflues
du jeu de résultats.
Pour comparer les performances,
examinons la sortie STATISTICS IO
provenant de la procédure stockée finale.
Exécutez GetInvoiceDetails3 avec
STATISTICS IO sur ON :

SET STATISTICS IO ON
EXEC GetInvoiceDetails3 1

vous obtenez la sortie statistique suivante
:

Table ‘Items’. Scan count 13,
logical reads 26, physical
reads 0, read-ahead reads 0.
Table ‘Leases_Items’. Scan count
1, logical reads 2, physical
reads 0, read-ahead reads 0.
Table ‘Leases’. Scan count 1,
logical reads 2, physical reads
0, read-ahead reads 0.

Si l’on part des nombres originaux
de GetInvoiceDetails, de 35 balayages
et 70 lectures logiques de 7 tables, les
statistiques ont chuté spectaculairement
à  15 balayages et 30 lectures de 3
tables – moins de la moitié du total initial.
C’est une grande économie de
performances pour une opération courante.
Nous avons vu comment, par une
relation moins courante, on peut améliorer
réellement la performance. Fort
de ce constat, j’espère que vous allez
commencer à  vous demander si la manière
classique et apparemment correcte
de concevoir votre modèle de
base de données est la seule méthode
– ou la plus efficace. Changer le
schéma d’une base de données opérationnelle
est un chantier important,
pas toujours pratique. Mais vos futurs
modèles de bases de données bénéficieront
sans aucun doute de votre exploration
des relations moins courantes.
Les relations « Big 3 » ne sont
qu’une partie du panorama de mise en
oeuvre des bases de données. Surtout,
ne vous reposez pas sur vos lauriers
une fois que vous les maîtriserez. Et, la
prochaine fois que vous lirez un texte
sur les relations de base de données,
ne vous empressez pas de fermer le
livre dès que vous en rencontrerez une
qui semble peu familière. Vos processeurs
vous en sauront gré.