Voici 5 principes à toujours avoir à l’esprit lorsque l’on créée une base de données relationnelle… afin d’obtenir les meilleures performances possible !

1) AUCUNE REDONDANCE : sinon cela augmente le volume de la base et multiplie les mises à jour par autant de données redondées, donc augmente la durée du traitement, donc, celle des verrous posés sur les tables, donc dégrade les performances et diminue la concurrence d’accès possible.

2) PAS D’ANOMALIE TRANSACTIONNELLE : la modification d’une valeur sémantique doit se traduire par la modification d’une seule donnée dans une seule table. Sinon il faudra mettre à jour de nombreuses lignes et c’est doublement pénalisant : durée de la requête plus longue, et verrouillage de la table plus long empêchant la concurrence.

3) LES DONNÉES DOIVENT ÊTRE ATOMIQUES : une colonne de table ne doit contenir qu’une seule information. En revanche, une vue peut contenir des données concaténées, agrégées, calculées… Une donnée non atomique se traduit par des requêtes alambiquées (SUBSTRING par exemple), OU, multiples critères dans la clause WHERE et souvent par l’incapacité à utiliser les index. En sus cela empêche une évolution aisée de la structure de la base.

4) LES COLONNES D’UNE TABLE DOIVENT CORRESPONDRE À DES ATTRIBUTS PROPRE À L’ENTITÉ QUE LA TABLE MODÉLISE : un numéro de téléphone, un mail ou une adresse ne sont pas des attributs propre à une personne, mais relatif à une table de téléphone, de mail ou d’adresse associé à la personne. En créant des tables artificiellement obèses (nombreuses colonnes), les requêtes sont plus complexes, l’accès aux données se fait la plupart du temps par balayage de la table (aucune utilisation d’index), la durée de verrouillage est très notablement allongée, et la concurrence de beaucoup plus faible, car c’est toujours la même table qui est impactée par les mises à jour.

5) LES CLEFS PRIMAIRE DES TABLES DOIVENT ÊTRE CONCISES, ASSÉMANTIQUE ET INVARIABLE : la meilleure clef primaire est un auto-incrément de type INT ou BIGINT. Car courte (4 ou 8 octets, c’est-à-dire la longueur du mot du processeur en 32 ou 64 bits), assémantique (aucune signification de la données dont la valeur est arbitraire) et invariables (la clef ne sera jamais mise à jour). Avec une telle clef, et si les FOREIGN KEY sont correctement indexées, peu importe le nombre des jointures, car contrairement à ce qu’écrivent de nombreux benêts, ce n’est pas la jointure qui pose des problèmes de performance, mais l’encombrement de la RAM avec des tables obèses, et l’impossibilité d’exploiter les index avec des tables ne respectant pas ces principes de modélisation…

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *