Les différences entre les champs VARCHAR et INTEGER dans les clés

J’utilise des identifiants entiers comme clés primaires dans mes tables. Et si j’utilisais plutôt des champs varchar ? Vais-je perdre en performance dans ce cas, surtout pour les grandes tables ? Les jointures fonctionneront-elles aussi rapidement qu’avec une colonne entière ?

Vos performances devraient être à peu près les mêmes avec des varchar ou des entiers. Firebird compare toujours les clés d’index octet par octet et seule la partie significative de la valeur est stockée.

Une clé à champ unique est d’abord convertie en l’un des trois types canoniques : chaîne avec collation, double précision et (malheureusement) entier 64 bits. Les dates deviennent des nombres à virgule flottante en double précision.

Les chaînes ayant une collation autre que leur valeur octet sont converties dans leur format de collation. C’est un peu un art noir et cela augmente la taille de la chaîne, mais le résultat est que la chaîne trouve sa place correcte lorsqu’elle est triée avec d’autres chaînes de la même collation. ‘A’, ‘a’, ‘â’, ‘á’, ‘Ă’, ‘ã’, ‘ä’, ‘å’, ‘ă’, ‘ą’, ‘Ā’ apparaissent tous à leur place désignée. (Désolé pour ce que cela a fait à votre client de messagerie …. dans le mien, ce sont onze variantes de ‘A’.) Les espaces de fin ne sont pas inclus dans la clé.

Le nombre en double précision est modifié pour qu’il se trie également octet par octet - approximativement inverser le signe, puis l’exposant, puis la mantisse, en tronquant les zéros de fin.

Selon l’endianness des entiers 64 bits sur l’ordinateur, ils sont également modifiés pour être comparés octet par octet. Cela peut sembler être une désoptimisation, mais les clés d’index ne sont pas stockées sur des limites naturelles et elles subissent une compression de préfixe, il n’y a donc aucun moyen d’utiliser une comparaison plus grande qu’octet par octet.

Les clés composites sont à peu près les mêmes. Chaque partie est convertie en son type de clé d’index et complétée à un multiple de 4 octets. Après chaque quatre octets, Firebird ajoute un octet avec la position du champ actuel de la clé. Ainsi, un index sur LastName, FirstName, ZodiacSign donnerait 1Harr1ison2Ann 3Gemi3ni. Cela évite la confusion embarrassante entre Damnation et Dam nation.

Pourquoi ai-je dit « (malheureusement) » ci-dessus ? Parce qu’avoir un format unique pour les nombres permet à Firebird de changer la taille des nombres sans recréer les index sur ceux-ci. Mais lorsque Borland a réintroduit les entiers 64 bits - InterBase avait des entiers 64 bits depuis le début sur les Vaxes - quelqu’un de brillant a réalisé que la double précision a 56 bits de précision et que les entiers 64 bits en ont 64. D’un autre côté, les index Firebird sont conçus pour gérer une certaine imprécision … ou les 8 bits restants pourraient être ajoutés à la fin … peu importe. Vous devez donc reconstruire les index lorsque vous passez de Numeric/Decimal 9 à Numeric/Decimal 12. Triste.

« Compression de préfixe ? » Lors du stockage d’une clé autre que la première sur une page ou la première après un saut sur une page, Firebird examine la clé précédente et tronque la partie du début de la clé suivante qui duplique son prédécesseur et ajoute la longueur de la partie tronquée au début. Ainsi, les chaînes “AAAA”, “AAAB”, “AAAC”, “AABC” deviennent

“AAAA”, “3B”, “3C” et “2BC”. Il y a un problème avec certains formats de GUID qui placent la partie volatile du nombre en premier, suivie de la partie fixe. Cela contrecarre la compression de préfixe et gonfle la taille des index.

« Saut ? » - La compression de préfixe réduit considérablement la taille des index, réduisant les E/S, mais nécessite de lire toute la page pour déchiffrer la clé. C’est bien avec des pages de 1 Ko, mais avec des tailles de page plus grandes, le calcul était inacceptable. Chaque page d’index a donc maintenant son propre index pointant vers les décalages des entrées non compressées. Cet index est appelé un vecteur de saut.

Ann Harrision