Analyser l’existant
Vous pouvez optimiser la structure de vos tables existantes en analysant leur contenu, après bien sûr un certain temps d’exploitation. Pour cela, il suffit de faire appel à la procédure ANALYSE
fournie par MySQL :
SELECT * FROM employee PROCEDURE ANALYSE(nb_de_colonnes);
L’analyse se fera sur les nb_de_colonnes
premières colonnes de la table. Vous aurez alors tout un rapport sur le contenu des données par champ : la valeur min, max, la structure conseillée correspondante.
- Choisir
CHAR
ouVARCHAR
? - Stocker les fichiers dans la table (TEXT/BLOB), ou sur un FTP ?
- Conseils sur les types de nombres
- Utilisation des
ENUM
- Utilisation des
SET
Le CHAR
occupe plus d’espace disque, mais son traitement est beaucoup plus rapide. Le VARCHAR
fragmente les données, donc les rend en partie moins stables, mais permet d’économiser beaucoup de place.
Le fait de stocker dans la table alourdit la base, et si le fichier est trop volumineux, celui-ci peut être tronqué sans qu’on ne soit prévenu. De plus, ils ont plus de chance d’être fragmentés. Mais cela peut aussi apporter des avantages. Comme par exemple bénéficier de la réplication MySQL entre les serveurs, de l’indexation fulltext, de tout centraliser dans un seul et même backup. A vous de voir maintenant !
Le choix entre un DECIMAL
, FLOAT
, ou DOUBLE
importe peu, la différence n’est pas trop grande. Par contre le choix entre un TINYINT
, SMALLINT
,MEDIUMINT
, INT
, ou BIGINT
permet d’économiser de nombreux et précieux octets.
Pour spécifier l’âge d’une personne , par exemple, on pourra choisir de le typer UNSIGNED TINYINT
ce qui nous donne une palette de 0 à 255, largement suffisant. UNSIGNED
permet de récupérer le bit qui détermine le signe pour le nombre, on gagne donc une puissance de 2 (de 0 à 255 au lieu de -127 à +127). Pour le détail sur l’occupation mémoire des types de nombres, je vous renvoie à la doc MySQL.
Comment feriez vous pour préciser la fonction d’un employé ? Disons qu’il existe : ‘CADRE’, ‘NON CADRE’, et ‘NON DEFINI’. Deux possibilités s’offrent à nous. On peut créer une table de fonction
contenant 3 lignes, et qu’on va joindre à la table employe
pour en définir la fonction. C’est ce qu’on trouve dans une base de données relationnelle pure. Et c’est la meilleure solution à adopter dans le cas ou la table fonction
doit être utilisée pour d’autres relations. Du point de vue des performances, cela oblige à alourdir la requête d’une jointure pour simplement connaître la spécialisation d’un objet. Il est alors permis d’envisager d’utiliser un type ENUM
qui va définir pour chaque ligne, directement, la fonction de l’employé.
On n’y pense pas forcément, mais il existe également un type SET
, ressemblant au type ENUM
, mais qui permet de définir non pas 1, mais plusieurs valeurs possibles pour un champ. C’est une technique qui n’est pas forcément facile à expliquer, mais pour ceux qui connaissent un peu la commande chmod
d’unix ,c’est le même principe. Chaque valeur du SET
est en fait une valeur puissance de 2, qui s’écrit en binaire avec un 1 et de 0 à n
0. La superposition de ces valeurs permet de déterminer l’ensemble des valeurs pour ce champ. Exemple, le champ vaut 11. En binaire, cela donne 1011. La champ prend les valeurs 1, 3 et 4 des valeurs définies par le SET. Petit lien vers la doc MySQL.