Le schéma de base de données SuperSub

Items. Trois tables Subtype –
Furniture, Trucks et Computers – font
référence à  Items, la nouvelle table
Supertype. De plus, les attributs courants
Manufacturer (Make), Model et
LeaseRate sont passés dans la table
Supertype Items. Le schéma est ainsi
beaucoup plus efficace parce que l’information
de détail de location se
trouve maintenant dans la table Items,
pas dans les tables Subtype. Par conséquent,
la procédure stockée chargée
de générer le rapport lease-detail,
GetInvoiceDetails2, est bien plus petite,
comme le montre le listing 2, et
moins gourmande en ressources.
Pour démontrer la différence de
performance, exécutons GetInvoice-
Details2 sur la base de données
SuperSub:

USE SuperSub
GO
EXEC GetInvoiceDetails2 1

GetInvoiceDetails2, il suffit maintenant
d’interroger trois tables seulement
pour obtenir le même lease report que
renvoie la première procédure. Le premier
bloc renvoie l’information article,
le deuxième bloc renvoie le montant
total mensuel facturé. La requête suivante
produit le même rapport :

SET STATISTICS IO ON
EXEC GetInvoiceDetails2 1

Toutefois, les nombres STATISTICS
IO ont chuté :

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

GetInvoiceDetails2 produit 29 balayages
et 58 lectures logiques sur trois
tables. C’est 6 balayages, 12 lectures et
4 tables de moins que GetInvoice-
Details – une économie notable, mais
on peut faire encore mieux.