logo le blog invivoo blanc

Optimisations des requêtes SQL – Partie 1

26 octobre 2015 | Big Data

Dans cet article, je vais aborder quelques techniques et bonnes pratiques pour aboutir à un modèle de données efficace et maintenable.

 Aujourd’hui la performance et la rapidité d’accès aux données sont parmi les enjeux majeurs des entreprises.  Ce qui leurs oblige dans plusieurs cas de revoir leurs modèles de données et de les faire adapter afin d’avoir un accès rapide à l’information. Alors si les SGBDR sont dotés d’un optimiseur, cela n’empêche pas ce dernier de se tromper ou d’être limité par le carcan de votre expression de requête. De plus l’optimiseur étant interne au SGBDR, il n’a aucune influence sur le SGBDR lui-même, la machine ni l’infrastructure du réseau, élément décisif en matière de rapidité de traitement des flux de données.

Voici donc, quelques points qu’il faut prendre en considération pour accélérer votre SGBDR et l’exécution des requêtes SQL !

Normalisation

La normalisation correspond au processus d’organiser ses données afin de limiter les redondances, divisant une table en plusieurs, et en les reliant entre elles par des clefs primaires et étrangères. Le non-respect des formes normales, conduit systématiquement à décrochage des performances dès que le volume des données de la base dépasse la quantité de RAM.

La normalisation introduit en tout 8 formes normales.

Les formes normales
Forme Implication
1NF First Normal Form Chaque table doit avoir une clef primaire. Il faut éliminer les colonnes en doublon. Chaque ligne doit contenir une seule valeur.
2NF Second Normal Form Si une table dispose d’une clef, toutes les propriétés doivent en dépendre : les données que l’on retrouve dans plusieurs lignes doivent être sorties dans une table séparée.
3NF Third Normal Form Les données d’une table ne dépendent que de la clef, et pas d’une autre colonne de la table : toute colonne dépend non seulement de la clef, mais également d’une autre colonne qui doit être sortie dans sa propre table.
BCNF Boyce-Cod Normal Form Aucune propriété faisant partie de la clef d’une relation 3NF, ne doit dépendre d’une propriété ne faisant pas partie de la clef primaire. Il faut donc créer une nouvelle table dont la clef primaire sera la propriété dont provient la relation.
4NF Fourth Normal Form Il ne doit y avoir qu’une et une seule dépendance multivaluée élémentaire.
5NF Fifth Normal Form Toute dépendance de jointure est impliquée par des clefs candidates de la relation.
Domaine/key Normal Form Il ne doit exister aucune contrainte sinon celles de domaine ou de clef.
6NF Sixth Normail Form La sixième forme, encore récente, demande à prendre en compte la dimension temporelle.

Par exemple pour modéliser une adresse postale, la plupart du temps les développeurs modélisent une adresse sous la forme d’une chaine de caractères. Là  qu’on veut écrire une requête qui cherche toutes les personnes qui habitent à la ville X,  et là c’est la panique… Lorsque la requête est écrite (ce qui est rarement arrivée…) elle est catastrophiquement lente du fait de multiples fonctions. C’est à ce moment que le développeur s’est rendu compte que cela aurait été mieux s’il avait modélisé cette adresse comme suivant :

  • Numéro
  • Rue
  • Ville
  • Code postal

Avec cette stratégie, les requêtes vont devenir plus simples à écrire et plus rapide en exécution.

Indexation

Un index est un objet complémentaire (mais non indispensable) à la base de données, son but principal est d’accélérer la recherche dans la base de données.
Toutefois la création d’index utilise de l’espace mémoire dans la base de données, et se mis à jour à chaque insertion ou modification de la table à laquelle il est rattaché. Donc il faut que la création d’index soit justifiée sinon ça va alourdir le temps de traitement de la base de données.
La création d’index se fait comme suivant :

CREATE [UNIQUE] INDEX Nom_de_l_index
ON Nom_de_la_table
(Nom_de_champ [ASC/DESC], ...)

⇒ Les options ASC/DESC permettent de définir un ordre de classement des valeurs présentes dans la colonne