TROISIÈME PARTIE : LE MODÈLE DE DONNÉES
Optimiser une base de données simplement par la qualité de son modèle est une chose simple, très efficace et à coût nul... Voila qui devrait intéresser beaucoup de monde. Or c'est souvent l'inverse qui se passe : le peu d'attention apportée au modèle, le peu de précaution dans le choix des types de données, le peu de respect des formes normales sont autant d'icebergs qui ne vont pointer leurs nez qu'au moment une base de données à raison d'une table pour un fichier est un échec assuré dont beaucoup d'éditeurs de solutions informatiques ont fait les frais.
Ce nouvel article a donc pour but de vous faire comprendre ce que sont les données, les types de données et la modélisation dans la perspective d'optimisation d'une base et donc d'un serveur. Toute application avec une forte implication de SGBDR commence par une modélisation des données. La qualité d'un modèle de données, ne se fera sentir que lorsque ce dernier sera mis à l'épreuve du feu, qui dans l'univers des SGBDR consiste à farcir ses tables qu'une quantité phénoménale de données et jouer les requêtes les plus fréquentes afin d'en mesurer les temps de réponse. Or cette phase est rarement entreprise en test. Elle l'est généralement en production.
C'est là qu'est l'os, hélas1, car il est déjà trop tard ! Lorsqu'un modèle de données est établi, et que le poids du volume des données se fait sentir, alors tenter de le remodéliser pour gagner des performances est un chalenge difficile : les évolutions du schéma conduisent à des migrations de données importantes (donc risquées) et des modifications d'interfaces conséquentes (donc du code à récrire). Lorsqu'il s'agit d'une base de données volumineuse, l'inertie des données peut être telle que l'alternative est s'adapter avec un coût de modification élevé ou mourir. C'est pourquoi un modèle de données bâclé présente la particularité d'avoir un coût très élevé lorsqu'il doit être rectifié, alors qu'un modèle peaufiné présente un coût quasi nul si l'on utilise l'outil adéquat et l'homme d'expérience.
Malheureusement, les français ont beau avoir inventé une méthode de modélisation d'une grande simplicité (MERISE2) il n'en demeure pas moins que peu d'informaticiens savent modéliser les données de manière intelligente. Bref, ce sont de ces écueils que je veux aujourd'hui vous entretenir, et pour cela, j'ai découpé en différentes parties le présent article. La première traite des types de données, la seconde des clefs, la troisième des tables et la quatrième de la normalisation.
Optimisation des bases de données SQL Server Troisième partie
Lorsque j’aborde les cours sur le langage SQL et que nous en sommes aux types de données, je pose souvent l’innocente question "quel intérêt y a-t-il à avoir un type de chaîne de caractères à longueur variable (VARCHAR) et un autre à longueur fixe (CHAR) ?" A ce jour, aucun de mes élèves ne m’a jamais donné la réponse attendue… Or l’intérêt, c’est le choix ! Tantôt je vais utiliser tel type pour telle raison et tantôt ce sera un autre.
Pour bien comprendre les caractéristiques des différents types de données il faut à nouveau se plonger au coeur du fonctionnement d’un SGBDR et tenter d’imaginer comment sont stockées les données dans les pages de la base. La différence fondamentale entre un CHAR de longueur n et un VARCHAR de même longueur, c’est que les données stockées dans le premier sont complétées à droite par un caractère de remplissage (le blanc, référence 20 en code ASCII), tandis que pour le second, on stocke la longueur vraie.
Mais si la ligne de la table comporte plusieurs colonnes de longueur variable, comment savoir ou commence et ou se termine chaque élément de données ? Avec une taille fixe, c’est facile, il suffit de compter les octets et l’on sait tout de suite quel est le découpage des données composant la ligne. Avec des éléments de taille variable, il faut rajouter une information supplémentaire afin d’indiquer ou se termine chaque donnée. En l’occurrence, dans SQL Server il faut ajouter deux octets pour chaque colonne de taille variable, car ces dernières peuvent aller jusqu’à 8000 octets.
Avantage du VARCHAR, son économie de place lorsque la longueur des données à y stocker peut varier dans d’importantes proportions, par exemple comme les lignes d’une adresse. Inconvénient, la nécessité d’un calcul supplémentaire pour trouver l’emplacement de la donnée, ainsi qu’une augmentation de la longueur des lignes pour y stocker l’information du nombre de caractères. Une des caractéristiques perverse du VARCHAR est sa forte propension à fragmenter les structures de données lors des modifications de valeurs. Pour obtenir de bonnes performances et gagner de la place, les données d’une ligne sont structurées de la manière suivante : toutes les colonnes de taille fixe sont placées au début, celles de taille variable à la fin.
En effet, avec cette organisation, seules les colonnes de taille variable ont besoin d’une information supplémentaire pour la longueur. Mais que se passe t-il si une donnée de longueur n est modifiée en une données de longueur n + i ? Il n’est plus possible de stocker la donnée dans son emplacement original. C’est d’ailleurs le même phénomène qui s’est produit avec moi quand lors de mon premier été d’installation en Provence, je me suis laissé aller à la sieste, la pétanque, le pastaga3 et le rosé : à l’automne, aucun de mes pantalons n’accueillait plus ma bedaine !
Il en va de même dans SQL Server, le "pantalon" ligne ne peut plus recevoir la donnée et cette dernière est rejetée sur une autre page, provoquant des lectures en zig-zag. Seul moyen de correction : la réindexation. Seul moyen de l’éviter : adopter du CHAR! Résumons-nous : si le littéral est de longueur faible ou fortement mis à jour ou encore si la donnée est d’une taille proche du maximum, préférez une taille fixe. Dans le cas contraire : grande taille, peu de mise à jour, données de longueurs très fluctuantes, alors la taille variable vous fera économiser de la place, donc du volume, donc de la mémoire, donc plus de lignes seront traitées directement dans le cache…
Dans un genre différent, on trouve la problématique du stockage des données littérales de type UNICODE en comparaison à l’ASCII. En unicode, chaque caractère est représenté par deux octets permettant ainsi 65 536 symboles, ce qui permet de marier les alphabets latin, grec, cyrillique, hébreu, asiatiques et bien d’autres encore. En ASCII 84 bits, il n’y a bien évidemment qu’un seul octet par caractère ! D’ou une économie de coût de stockage de moitié si l’on travaille en ASCII (donc CHAR, VARCHAR) comparé à la version UNICODE (NCHAR, NVARCHAR, le N voulant dire NATIONAL).
Il y a donc une sacrée différence de performance entre 1 et 2 octets. Le double tout simplement. Or il est rare qu’une application soit à la fois internationale et internationalisée. Internationale au sens ou tout être humain quelles que soient sa nationalité, sa culture et en particulier sa langue soit en mesure de l’utiliser, et internationalisée, au sens où des utilisateurs de cultures différentes et donc de langues différentes vont devoir utiliser la même application en même temps. Les rares cas que je connaisse consiste en des sites web interactifs planétaires où l’on s’est simplifié la vie en imposant finalement l’anglais comme langue commune !
Téléchargez cette ressource
Guide de technologie 5G pour l’entreprise
Pourquoi la 5G est-elle faite pour votre entreprise ? La 5G peut améliorer la vitesse, la fiabilité et la capacité de votre réseau, permettant ainsi une meilleure collaboration, une productivité accrue et une prise de décision plus rapide. Notre livre blanc " The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.
