Char ou Varchar

Lors de la définition des tables dans une base de données, nous sommes souvent confronté à savoir si nous devions placer les colonne de type alphanumérique en “char” ou “varchar”.

Plusieurs diront que si la longueur est plus petite de 10, il faut mettre “char” sinon on indique “varchar”. Le seul problème avec cela, c’est qu’en mettant le type en “char”, la longueur de la colonne est fixe. Si on insère 3 caractères dans cette colonne, la longueur sera toujours de la longueur maximale de la définition de la colonne, le reste des caractères seront des espaces, ce qui peut amener des problèmes lors des recherches avec ces colonnes.

J’ai effectué les tests avec une installation Oracle 11G R2 pour la simplicité de la démonstration.

J’ai créé une table test avec 2 colonnes, une de type char(30), et l’autre varchar2 (30) . Le type varchar2 correspond au type varchar pour les autres SGBD dont SQL SERVER.

J’ai inséré quelques données et voici ce que ça donne

CREATE TABLE tchar ( nom char (30), descr varchar2 (30));

INSERT INTO tchar VALUES ( ‘Pomme’, ‘Pomme’);
INSERT INTO tchar VALUES ( ‘Bananes’, ‘Bananes’);

SELECT nom, dump( nom) dump_nom, descr, dump( descr) dump_descr FROM tchar;

Résultats :

Pomme                              Typ=96 Len=30: 80,111,109,109,101,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32     Pomme     Typ=1 Len=5: 80,111,109,109,101
Bananes                            Typ=96 Len=30: 66,97,110,97,110,101,115,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32     Bananes     Typ=1 Len=7: 66,97,110,97,110,101,115

J’ai utilisé la fonction dump  pour afficher le code du type de données, la longueur en octets et les codes caractères.Cette fonction est native sur le SGBD Oracle.

Si on compare des pommes avec des pommes, on s’aperçoit que c’est pas identique en char et en varchar. La colonne de type char, contient toujours une longueur fixe. Qu’on place des bananes ou une pomme comme valeur, la longueur sera toujours de trente en ajoutant des espaces à la fin de la chaine (code ASCII 32). Par contre, si on regarde la colonne de type varchar2, la longueur varie et contient le nombre de caractères désirés.Ce qui indique que le type varchar2 ne prend pas plus d’espace qu’utilisé réellement.

Par contre, si la base de données est configurée en UTF-8, tous les caractères accentués ou étendus auront également le code unicode de langue devant le caractère accentué ou étendu.

INSERT  INTO tchar VALUES ( ‘École’, ‘École’);
commit;

Résultat :

École   Typ=96 Len=30: 195,137,99,111,108,101,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32 École Typ=1 Len=6: 195,137,99,111,108,101

On voit également que lorsqu’on utilise un caractère unicode,  l’espace occupé a doublé parce que le code unicode requiert 2 octets. Ce code peut prendre jusqu’à 4 octets selon le caractère unicode inséré.

Donc, dans tous les cas, il est préférable d’utiliser le type varchar au lieu de char pour les colonnes de type alphanumériques. Cela permet également de sauver de l’espace disque même si cela importe peu de nos jours, sauf pour dire que nous ne gaspillons pas les ressources qui sont à notre disposition.