> Tech > Qualité d’une bonne clef

Qualité d’une bonne clef

Tech - Par iTPro - Publié le 24 juin 2010
email

S'il est une race de données entre toutes qui doit mériter l'attention la plus extrême, c'est bien celle qui se cache derrière la ou les colonnes constituant la clef d'une table. À l'école, on apprend bêtement que la clef d'une relation doit être choisie parmi les attributs de cette dernière.

Qualité d’une bonne clef

Dès lors s’il nous faut identifier une personne, et cela avec l’interdiction cnilesque15 d’utilisation du NNI16, il est concevable que tout un chacun utilise les attributs NOM + PRENOM + DATE_NAISSANCE, voire quelques autres éléments si statistiquement le volume des données à traiter risque d’être élevé. Comme cet exemple est en matière de performances, le pire de tous, voyons quels en sont les inconvénients. D’abord, c’est long, et contrairement au dicton, plus c’est long, plus c’est mauvais !

Une clef composée de 40 caractères par exemple provoque des calculs beaucoup plus complexes qu’un nombre, notamment lorsqu’il faut faire des jointures ou des tris17. Ensuite, c’est mouvant18. En effet, le nom d’une personne peut changer, notamment lorsqu’elle se marie. Cela va donc entraîner une quantité phénoménale de modifications, et risque de créer des faux19. Enfin, c’est lourd. Écrire des requêtes avec des jointures qui nécessitent 3 colonnes mises en relation… Quelle fatigue !

Nous pouvons donc en déduire quelques éléments concernant la qualité d’une bonne clef. Elle doit être :
• la plus courte possible ;
• stable dans le temps ;
• composée d’une seule colonne.

A l’évidence une clef dont la longueur ne dépasse pas la longueur du mot du processeur20 est parfaite au niveau des calculs machiniques. A l’évidence, la stabilité dans le temps ne peut être vraie que si la clef ne revête aucune sémantique21 dans l’univers modélisé.

Se pose alors la question : quel type de données est le plus apte à représenter une clef ? Une dernière condition va vous faire toucher du doigt la solution : plus le type considéré peut représenter différentes valeurs, plus il sera facile à utiliser pour des tables volumineuses. Ainsi, l’utilisation d’une clef littérale composée de 4 caractères est battue à plate couture par l’entier 32 bits : les caractères inférieurs à 20 (espaces) sont réputés non imprimables, donc quasiment impossible à saisir, de plus certains caractères au dessus de 128 sont difficiles à frapper au clavier.

On ne peut donc compter que sur environs 100 caractères différents, ce qui fait du littéral de 4 caractères une clef ne pouvant représenter que 100 millions de tuples différents. Alors que notre simple entier limité aux valeurs positives permet déjà plus de 2 milliards de combinaisons… D’où l’intérêt d’une clef purement numérique et attribuée au hasard à chaque nouvelle insertion. Au hasard ? Nous y reviendrons… Car le hasard ne fait pas bien les choses.

En revanche, l’auto incrément, avec le bon index, si ! Mais, il y a parfois quelques idées fumeuses qui traînent en matière de conception de données et de modélisation de clefs. Pour anecdote, il y a quelques années un internaute m’apostrophe par un mail22 en me demandant de lire un e-paper concernant un truc génial sur les clefs… Un informaticien avait eu la bonne idée de préconiser l’utilisation du GUID (vous savez cet identifiant universel généré au hasard et qui pèse 32 octets). Dès lors, plus besoin de clef primaire, plus besoin de contraintes d’unicité ! La merveille des merveilles… Sauf en ce qui concerne le coût et les performances. Calculer un GUID est très complexe et 32 octets, nécessite 8 passes dans le processeur à chaque traitement. Bref ce génie avait inventé la clef qui tue !

On notera donc qu’une bonne clef est un entier de la longueur du mot du processeur et par défaut attribuée automatiquement pas auto incrément. Seule ombre au tableau, l’insertion massive de lignes dans une table avec une clef auto incrémentée provoque un phénomène bien connu des quinquagénaire ayant connu les rames Thompson du Métropolitain de Paris : ça se bouscule au portillon ! Néanmoins sachez-le, la contention liée à ce problème s’est nettement améliorée depuis les toutes dernières versions de SQL Server. En revanche, un des avantages considérables de l’utilisation des clefs sur auto incrément est qu’il minimise la fenêtre des données.

Comment cela est-il possible ? Simplement par le fait que, statistiquement, nous utilisons beaucoup plus fréquemment les lignes les plus récemment insérées, donc, celles situées vers la fin de l’index plutôt que les plus anciennes. Cela est vrai pour les données comptables, les salaires, les commandes mais aussi dans une moindre mesure pour les biens à vendre ou encore les clients…

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010