VARCHAR VS CHAR

[zwejdi]

salut tous le monde.

es ce vrai que le type de données varchar(XX) est deconseillé pour les champs d'une table lorsque celle la est sollicite en modification ? et que l'utilisation du type char(XX) est recommandé ?

quels sont les avantages et les inconvenions de ces deux types de données ?

merci d'avance pour vos reponces

[jab]

A priori, le type char étant fixe, longueur définie par avance, le traitement de ce type de champ est plus rapide. Par contre, char(250) va occuper systématiquement 250 bytes mêm si il y en a 20 occupés.

La problématique est simple, tu écris un record avec un varchar(250) remplis de 12 caractères. Il en stocke réellement 12 et ne réserve rien. Tu modifie et il contient maintenant 32 caractères. Comme il n'y a pas de réservation de place, le traitement est plus long.

Avec un char(250) tu n'a pas ce problème mais tu gonfle la taille de ta table. En terme de performance, il faut aussi tenir compte que dans ce cas la lecture des enregistrements sera plus lourde vu la taille du record.

Si la place occupée prime sur la rapidité de mise à jour (grande table, peu de mise à jour) alors utilise du varchar.
Sinon utilise du char pour les champs texte de taille réduite et du varchar pour les longs champs texte. Ainsi tu as un compromis.

A toi de voir au cas par cas.

[zwejdi]

merci jab pour tes precieuses consignes

Envoyé par jab

La problématique est simple, tu écris un record avec un varchar(250) remplis de 12 caractères. Il en stocke réellement 12 et ne réserve rien. Tu modifie et il contient maintenant 32 caractères. Comme il n'y a pas de réservation de place, le traitement est plus long.

lorsque je modifie un enregistrement de type varchar, les données ajoutées en plus seront stockées qq part et un sorte de chainage sera crée. si cette operation de modif est fraquante, ca influe forcement sur les performances de l'SGBD, est ce que un reorge table reméde a ce probléme ?

[jab]

Envoyé par zwejdi

lorsque je modifie un enregistrement de type varchar, les données ajoutées en plus seront stockées qq part et un sorte de chainage sera crée. si cette operation de modif est fraquante, ca influe forcement sur les performances de l'SGBD, est ce que un reorge table reméde a ce probléme ?

Ce n'est pas sur. Je pense plutôt qu'il réécrit l'enregistrement complet ailleur et qu'il marque la version précédente comme supprimée. L'impact sur les perfs est moins importante. Par contre la table devient un gruyère et le reorg a alors toute son utilité. Mais ce n'est que mon avis prsonnel. Je ne sais pas comme travail le moteur.

[pdz74]

Je confirme : un DELETE est logique et non physique. DB2 positionne un indicateur pour préciser que la ligne n'existe plus, mais elle est encore présente physiquement sur disque. Seule une REORG supprime physiquement cette ligne et récupère l'espace disque.

Concernant CHAR ou VARCHAR, ne pas oubliez que le COMPRESS de DB2 fonctionne bien et permet de se servir de CHAR sans pour autant perdre d'espace disque en stockage. Par contre, il est vrai que les outils de compression/décompression consomme un peu de cpu et qu'au moment du SELECT, DB2 récupère 250 octets avec du CHAR, ce qui peut être consommateur pour des tris par exemple.