N° erreur : 16
Niveau : Alerte
Constat
Une rubrique texte qui ne contient que des valeurs numériques doit être analysée.
Dans le meilleur des cas, la rubrique est juste lue : il y a une perte de quelques octets par enregistrements.
Si cette rubrique est indexée, alors la densité de l’index est plus faible, entrainant une consommation supplémentaire pour l’analyse et / ou la recherches de clé dans les plans d’exécutions.
Dans le pire des cas, il s’agit d’une clé primaire : Le constat est le même que précédemment, sauf qu’il va être multiplié par le nombre de tables où la clé sera utilisée.
Ex :
Le stockage d’une valeur de 0 à 100 en chaine se fait sur 3 octets (ou 6, si elle est unicode, mais partons sur une analyse plus optimiste). Ceci peut entrer sur un entier d’un octet. Si j’y stocke 50 valeurs, je perds 100 octets (ok, rien d’important).
Cette clé est alors utilisés dans une table de 1 000 000 enregistrements -> 2Mo de perdu (sur le papier, ce n’est pas très grave non plus)
Je répète l’erreur pour X clés primaires, dans X tables, je me retrouve alors avec une masse d’index, à faible densité, qui seront analysés / scannés lors des jointures de mes requêtes.
Cette perte est unitairement peu perceptible. Si le serveur subit de fortes charges, c’est cette perte qui peut engendrer un engorgement pour une méthode de stockage, qui n’a aucune valeur ajoutée.
Solution à appliquer
Transformez vos chaines en une valeur numérique, des que vous le pouvez.
Annexe :
Si ce choix est motivé par l’idée disposer des ‘0’ à gauche, pour avoir une taille fixe; ou maitriser le nombre de décimales : stockez les données dans un format numérique adapté et transformez les en sortie.
Infos :
- Dans MySQL / MariaDB : Vous pouvez préciser le format d’affichage, dans la définition de la rubrique.
- Dans SQL Server : La fonction FORMAT permet de mettre en forme les données.
- Tous les autres : une procédure stockée peut faire le travail pour formatter les données à votre concenance.