Pour allouer ou ne pas allouer ?

longueur de champ maximale prévue
pour le champ. Dans notre cas,
c’était 500 – ce n’est pas très long pour
des URL, je sais. Mais cela faisait notre
affaire.
De toute manière, DB2 UDB for
iSeries offre une option peu connue
pour le type de donnée VARCHAR qui
influence grandement son utilisation :
ALLOCATE(n). Par exemple :

CREATE TABLE INTERNET_LOGS
   (URL VARCHAR(500)
   ALLOCATE(105)
   NOT NULL);

Ici, j’ai indiqué une longueur maximale
de 500 pour le champ URL et une
valeur de 105 pour ALLOCATE. Qu’estce
que cela signifie ? Que sans
l’ALLOCATE, DB2 UDB réservera un
bloc de 500 caractères pour chaque
ligne dans cette colonne. Certaines
URL peuvent comporter 500 caractères
mais, dans notre exemple, la plupart
utilisent 105 caractères ou moins.
L’option ALLOCATE signifie que DB2
UDB n’allouera que 105 caractères
pour le champ, avec des conséquences
positives sur l’espace de stockage.
Si la table rencontre une URL de
plus de 105 caractères, cette URL ira
dans une page de débordement qui,
lors de son accès, demandera plus
d’une lecture de page. Nous sommes
donc en train de maximiser l’espace de
stockage pour la majorité des URL tout
en sollicitant fortement les lectures
disque pour le nombre des URL qui
vont dans le débordement. L’astuce
consiste donc à  allouer (ALLOCATE)
statistiquement et minimiser les lectures
disque accrues. Dans notre cas,
nous allons exécuter le SQL suivant :

SELECT LEN,COUNT(*) FROM
  (SELECT LENGTH(TRIM(URL))
    AS LEN FROM INTERNET_LOGS) AS A
    GROUP BY LEN
    ORDER BY LEN;

Cette séquence comptait le
nombre de lignes de chaque longueur
particulière et nous avons représenté
ces données par une courbe dans
Excel. Cela nous a donné une distribution
normale qui nous a aidés à  déterminer
la valeur ALLOCATE à  utiliser.
(Elle se situerait à  la base, ou à  la chute,
de la courbe afin de couvrir la majorité
des URL.) Vous pouvez économiser
beaucoup d’espace (selon les longueurs
et les volumes des données)
tout en minimisant l’activité disque
supplémentaire. D’où la question : « A
quoi sert-il d’utiliser un VARCHAR sans
spécifier ALLOCATE ? » Vous pouvez
aussi bien utiliser CHAR(500) que VARCHAR(
500) (si vous n’utilisez pas
l’ALLOCATE ; au moins avec CHAR,
vous ne subirez pas les deux octets
supplémentaires utilisés par un VARCHAR.
Bien entendu, si une table est
volatile, il faudra la surveiller et l’insertion
soudaine d’un nombre d’enregistrements
plus longs que la valeur ALLOCATE
pourrait bien dégrader les
performances.