* 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 *
Version imprimable
* 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 *
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)
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.
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 ?
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.
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.Citation:
Envoyé par Garuda
Cordialement,
Franck.
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.Citation:
Envoyé par Garuda
Merci pour vos réponses !
mais la question était (reformulation):
NB : Personnellement, je ne m'en occupe jamais en exploitation, mais je n'utilise pas non plus une base gigantesque .Citation:
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 ?
Quant à utiliser autre chose que des VARCHAR2 pour stocker des chaines de caractéres, dieu m'en préserve !!!:zoubi:
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 ?Citation:
Envoyé par mnitu
Exemple : pour une champs 'commentaire' VARCHAR2(2000), 10 caractéres utlisés lors de l'iNSERT, 1500 caractéres lors de l'UPDATE,
Le varchar2 n’est pas le seul type de données qui occupe plus ou moins d’espace en fonction de sa valeur actuelle. C’est valable aussi pour le type number par exemple. Mais, un enregistrement peut également commencer avec beaucoup des colonnes ayant la « valeur » Null et finir par la suite d’un update avec toutes les colonnes contenant une valeur non nulle ce qui peut modifie d'une manière importante la taille de l’enregistrement.
Bonjour,
Pas que les chaînes de caractères. NUMBER est aussi à taille variable.Citation:
Envoyé par Garuda
'chained rows' c'est quand une ligne ne loge pas dans un block (ou aussi quand elle a plus de 255 colonnes). On ne peut pas faire grand chose à par avoir des blocs plus grands, ou mettre les colonnes les moins utilisées à la fin.
'migrated row' c'est quand une ligne modifiée, plus grande, ne loge pas dans le block. ca rallonge le temps d'accès par index à une ligne. Ca ne change pas grand chose au full scan. On essaie de mettre un PCTFREE qui correspond à l'évolution des données (cf tk-optimal-pctfree-initrans/)
Cordialement,
Franck.
ok . grand merci pour toutes ces excellentes réponses.:ccool: