Ne dénormalisez jamais, sauf…

des temps de traitement des mises à jour (INSERT, UPDATE, DELETE) sans avoir éprouvé le modèle avec un volume de données qui représente une masse proche de celle qui sera réellement exploitée. Lisez la discussion que nous avons eue sur Internet à ce sujet34.

Elle est pleine d’enseignement et riche de contradictions. Mais elle converge sur un point : aucune dénormalisation, sans avoir prouvé le bénéficie absolu que l’on peut en tirer ! N’ayez donc aucune crainte : un modèle performant est un modèle parfaitement normalisé. Il n’y a qu’à l’épreuve du temps, et donc à l’augmentation concomitante du volume que l’on pourra déceler les éléments candidats à une dénormalisation, en tester la pertinence et modifier en conséquence le schéma. Mais s’il faut dénormaliser, autant que ce soit avec le maximum de précaution : évitez la redondance dont le calcul s’effectue sur le client.

Choisissez toujours un mécanisme de redondance qui garantisse l’intégrité de la base. En cette matière, le choix est large. Ma préférence, va dans l’ordre aux techniques suivantes : vues indexées, colonnes calculées indexées, procédures stockées remplaçant les requêtes directes (avec une gestion de la sécurité afin d’interdire ces dernières), trigger. Dans certains cas on pourra précalculer des données agrégées par exemple chaque nuit et compléter le résultat si besoin est, avec les seules données du jour à l’heure d’exécution de la requête.

Dans tous les cas, mesurez le gain de temps en lecture. S’il est inférieur à 2, il vaudrait mieux s’abstenir, car les pertes des temps de traitement des mises à jour risquent de devenir pénalisantes. À partir d’un gain de 10, allez-y franco35. Avec un gain de 1000, facile à obtenir avec une bonne vue indexée s’il y des calculs d’agrégats, vous aurez le statut de magicien ! Vous n’êtes pas encore convaincu de l’intérêt d’un modèle solide et bien normalisé ? Vous voulez discuter de la chose ? Alors n’hésitez pas à me joindre par courriel36 à SQLpro@club-internet.fr