par Dusan Petkovic et Christian Unterreitmeier - Mis en ligne le 09/07/2002
Des données faussées peuvent affecter le plan d'exécution des requêtes
contenant un prédicat et de celles
contenant une opération de jointure. Apprennez à tenir compte de la distorsion
des données pendant
la conception de la base de
données ...
Les colonnes d'une table représentent
généralement les propriétés d'entités
concrètes comme des noms d'employés
et de produits. Quand votre requête
contient un prédicat - une
clause WHERE contenant des critères
de recherche - incluant une colonne,
l'optimiseur de requêtes SQL Server
peut trouver les données correspondantes
à la requête de deux manières
différentes : balayage de table ou accès
par index. Dans un balayage de table,
l'optimiseur lit séquentiellement
toutes les lignes d'une table et compare
chacune d'elle aux critères de recherche
de la clause WHERE. SQL
Server décide en général de balayer
toute la table quand la requête sélectionne
un nombre significatif de lignes
de la table. L'optimiseur de requêtes
opte plutôt pour l'accès par index
quand un index de colonne (clustered
ou nonclustered) existe. Utiliser ou
non l'index existant dépend de nombreux
facteurs différents.
Si l’optimiseur de requêtes doit
choisir le mode d’accès à une colonne
contenant des valeurs non uniques, la
distribution de valeurs distinctes pour
la colonne au travers des lignes d’une
table devient un facteur important.
Supposons que votre entreprise stocke
tous les noms de clients dans la table
customers, incluant deux clients nommés
gender et country. Supposons
également que l’entreprise soit principalement
implantée en Amérique du
Nord et que la colonne country ait 10
valeurs distinctes. Si 70 % des clients
habitent aux Etats-Unis, 10 % au
Canada, 5 % au Mexique et 0,05 % en
Allemagne, les valeurs distinctes dans
la colonne country ne sont pas distribuées
uniformément sur les lignes de
la table customers. Dans cet exemple,
les données de la colonne country sont
faussées parce que les valeurs de cette
colonne (Etats-Unis, Canada, Mexique,
Allemagne, etc.) apparaissent dans les
lignes de la table customers avec des
fréquences très différentes. A l’inverse,
la colonne gender contient à peu près
le même nombre d’hommes et de
femmes, donc les données de cette colonne
ne sont pas faussées. Voyons des
instructions SELECT différentes pour
voir comment l’optimiseur de requêtes
choisit de sélectionner le jeu de
résultats dans des situations différentes
dans lesquelles la colonne de
données faussées se trouve dans le
prédicat WHERE. Au préalable, il faut
écrire une instruction T-SQL qui crée la
table customers, illustrée dans le
listing 1. Vous pourrez ensuite utiliser
le batch que le listing 2 montre
pour charger 10.000 lignes dans cette
table.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
