De l’influence du type de données (2)

qui gère cette particularité de la norme SQL, la transformation d’un type SQL en un autre dans un modèle comportant de très nombreux attributs en sera grandement facilité, notamment pour ce qui est des littéraux. D’autant que SQL Server intègre de manière intelligente et performante la notion de domaine à travers ses user types, ses rules et ses defaults6. Puisque nous avons parlé culture, parlons des collations.

Non il ne s’agit pas de casse-crouter. Le terme collation possède un sens ancien plus profond : il s’agit de comparer des manuscrits, des textes… C’est ce que fait le pilote de l’Airbus A380 qui vous transporte au septième ciel lorsqu’il confirme dans sa voie l’ordre qu’il vient de recevoir du contrôleur aérien : "Vol 714 pour Sydney, veuillez monter à six mille pieds", "OK, ici vol AF 714, nous montons à dix mille pieds". Remarquez que dans le présent dialogue, la collation est mauvaise. Le but étant bien évidemment d’obtenir confirmation de l’ordre à exécuter en faisant répéter le destinataire.

Dans notre exemple, le contrôleur doit immédiatement réagir pour informer le pilote de son erreur et lui intimer de corriger sa trajectoire. De l’utilité de la collation. Encore un bon point pour SQL Server. Il implémente parfaitement bien la notion de collation notamment depuis la version 2000. Le seul hic : peu de gens le savent et très peu s’en servent ! Une collation au sens SQL du terme est un objet qui permet de définir le comportement de la chaîne de caractères qu’elle qualifie. Ce comportement piloté par la collation peut être le respect ou non de la casse7, le respect ou non de caractères diacritiques8, le respect ou non de la largeur d’encodage9, le respect ou non des différents types de caractères japonais Kana10 (Hiragana et Katakana) et pour finir l’ordre du tri des littéraux11…

Or la collation a un coût ! La comparaison d’éléments dissemblables n’est pas magique. Elle repose sur des algorithmes et des structures de données dont l’exécution est plus ou moins performante selon la collation adoptée. De plus les données littérales sont stockées d’une manière spécifique en fonction de la collation choisie, tant est si bien que tout changement de collation "on the fly" est impossible sans une migration des données. En revanche, il est clair que l’absence de collation, c’està- dire la comparaison binaire de chaînes de caractères (collation forte) est plus rapide qu’une collation faible (faisant confusion de la casse ou des accents par exemple).

Or cette collation sans collation a un nom, c’est la collation binaire ! En dehors de cette collation binaire12, toute collation provoquera plus de traitement dans toutes les manipulations de données littérales. Il semble donc intéressant de définir une collation binaire le plus souvent possible. Mais ou faut-il la mettre ? SQL Server accepte de définir la collation à différents endroits : le serveur, les bases, les colonnes et l’expression. Pour des raisons de performances, vous êtes invités à spécifier la collation au niveau du serveur et n’en changer que dans certains cas exceptionnels. Mais une collation binaire au niveau serveur est-elle bien adaptée à la majorité des cas ? Non seulement je dirais oui, mais l’usage d’une collation binaire à l’installation du serveur nous réserve une surprise de taille…

Comme nous l’a enseigné le bon Docteur Codd (règle n°4) la description des objets contenus dans une base de données doit être représentée, comme pour les données ordinaires, c’est-à-dire par des valeurs dans des tables. La conséquence est que si vous installez votre serveur avec une collation binaire, donc sensible à la casse, tous les noms des objets des bases de données doivent être écrits exactement de la manière dont ils ont été créés c’est en dire en respectant la casse et les éventuels caractères diacritiques. Loin de nuire à l’écriture du code et en particulier des requêtes, cette façon de faire minimise le cache des procédures.

En effet l’entrée et la recherche dans ce cache se fait par un tableau des chaînes de caractères décrivant les procédures et les requêtes. Pour aller le plus vite possible, les données de ce cache sont stockées en binaire et la comparaison s’effectue en hexadécimal. Si les noms des objets d’une même requête sont écrits tantôt en majuscules, tantôt en minuscules, tantôt avec une combinaison des deux, vous allez vous retrouver avec un cache encombré de multiples entrées pour une même requête avec les plans de requêtes associés, donc une augmentation considérable de la taille du cache, mais aussi un vieillissement prématuré de ces entrées, donc une perte plus rapide des plans préétablis du fait de l’algorithme LRU…

Bref, il est donc bénéfique à de nombreux niveaux d’utiliser une collation binaire, même si vos développeurs trouvent ridicule l’idée que l’écriture des requêtes SQL devienne sensible à la casse ! Faut-il utiliser un INTEGER, un SMALLINT, un TINYINT ou un BIGINT ? De manière similaire à la problématique des littéraux, lorsque l’on a le choix, il faut considérer les différentes options. Mais là on doit compter avec un paramètre supplémentaire : la taille du mot du processeur. En effet, l’optimisation ne sera pas la même si SQL tourne sur un OS 32 bits ou sur du 64…

Dans un environnement 32 bits, un entier de 64 bits (BIGINT) coûte un peu plus de 2 fois plus en traitement qu’un 32 bits (INT). En 64 bits un entier 32 bits coûte un tout petit peu plus en traitement qu’un 64 bits. La raison en est simple : le seul moyen, pour le processeur, de tester si le 32 bits en est réellement un (et donc qu’il n’y a pas d’overflow13 ) est de le contrôler algorithmiquement à l’aide d’une passe dans un circuit électronique microprogrammé. D’ou un surcoût de traitement de l’ordre de quelques pourcents. Autrement dit, pour des jointures entre clefs auto incrémentées, soit l’OS est 32 bits et ces données doivent être définies en INT, soit l’OS est 64 bits et il faut songer à mettre du BIGINT.

Quant à l’argument qui consiste à dire que le 64 bits est deux fois plus volumineux que du 32 bits, il est parfaitement concevable, mais va peser peu en regard du volume d’une ligne de la table. Songez donc si ce cas vous tourmente à réduire quelques-uns de vos CHAR d’un ou deux caractères et le tour sera joué !