Discussion :

[haykelFST]

* Bonjour, *

Dans quel cas préférer le type varchar2 au type char pour la définition d'une colonne de type caractère?

* Merci *

[punkoff]

Bonjour,

Dans la plupart des cas.

Un type char réservera la totalité de l'espace typé (sauf si null, à vérifier avec Oracle), tandis qu'un varchar ne réservera que la longueur de la chaine + 1 ou 2 octets pour connaitre la longueur de la chaine.

Au final on gagnera beaucoup en place disque pour peu que la base soit un peu plus grosse que 5mo (ne pas oublier aussi les index rattachés à cette colonne)

[Waldar]

Tom Kytes préconise même d'utiliser systématiquement VARCHAR2.

Le seul cas de figure où il utilise encore CHAR, c'est pour les CHAR(1) parce que c'est plus rapide à écrire.

[Garuda]

Pour mon info personnelle :

Il me semble que l'emploi de VRACHAR2 posait un problème lors de la modification de la longueur 'utile' d'un VARCHAR2 (dépassement de la taille de bloc et création de CHAINED ROWS). Ce problème existe-t-il toujours ? Si non , à partir de quelle version ? Si oui, cela est-il vraiment un problème ?

[pachot]

Bonjour,

Physiquement, c'est stocké de la même manière.
La seule différence c'est que CHAR va rajouter des espaces jusqu'à la taille maximale. Mais je ne vois aucune utilité à cela. Sauf s'il existe une raison métier pour considérer que 'TEXTE' est différent de 'TEXTE '. Et encore, autant rentrer directement la chaîne avec les espace plutôt que de s'appuyer sur un remplissage automatique.

De toute façon, tous les langages clients utilisent des chaînes à taille variable. Les stocker autrement en base de donnée n'est que source de problèmes.

Pour mon info personnelle :
Il me semble que l'emploi de VRACHAR2 posait un problème lors de la modification de la longueur 'utile' d'un VARCHAR2 (dépassement de la taille de bloc et création de CHAINED ROWS). Ce problème existe-t-il toujours ? Si non , à partir de quelle version ? Si oui, cela est-il vraiment un problème ?

La plupart des types de données sont à taille variable. Il vaut mieux utiliser PCTFREE pour réserver de l'espace pour les augmentations de taille plutôt que de remplir avec des espaces.

Cordialement,

Franck.

[mnitu]

Pour mon info personnelle :

Il me semble que l'emploi de VRACHAR2 posait un problème lors de la modification de la longueur 'utile' d'un VARCHAR2 (dépassement de la taille de bloc et création de CHAINED ROWS). Ce problème existe-t-il toujours ? Si non , à partir de quelle version ? Si oui, cela est-il vraiment un problème ?

Ce problème n'est pas liés aux type des données mais au manque d'espace disponible dans le bloc suite à un mise à jour d'un enregistrement.

[Garuda]

Merci pour vos réponses !

mais la question était (reformulation):

Selen votre expérience, est-ce que le fait de multiplier le nombre de bloc à lire lors du dépassement pose vraiment un problème d'exploitation et impose donc un traitement périodique des 'CHAINED ROWS' ou est ce que c'est un faux problème ?

NB : Personnellement, je ne m'en occupe jamais en exploitation, mais je n'utilise pas non plus une base gigantesque .

Quant à utiliser autre chose que des VARCHAR2 pour stocker des chaines de caractéres, dieu m'en préserve !!!

[Garuda]

Ce problème n'est pas liés aux type des données mais au manque d'espace disponible dans le bloc suite à un mise à jour d'un enregistrement.

Justement ! j'avais cru comprendre que les seuls cas ou cela pouvait se produire était lors de "l'agrandissement" d'une chaine (le 'variable' de varchar2) .Me trompe-je ?
Exemple : pour une champs 'commentaire' VARCHAR2(2000), 10 caractéres utlisés lors de l'iNSERT, 1500 caractéres lors de l'UPDATE,