Quelle est la principale différence entre Varchar2 et char

Bien qu'il existe déjà plusieurs réponses décrivant correctement le comportement de char , je pense qu'il faut dire que vous ne devriez pas l'utiliser sauf dans trois situations particulières :

1. Vous créez un fichier ou un rapport de longueur fixe et affectez une valeur non nulle à un char évite d'avoir à coder un rpad() expression. Par exemple, si firstname et lastname sont tous deux définis comme char(20) , puis firstname || lastname est une manière plus courte d'écrire rpad(firstname,20) || rpad(lastname,20) pour créer Chuck Norris .
2. Vous devez faire la distinction entre la chaîne vide explicite '' et null . Normalement, c'est la même chose dans Oracle, mais en attribuant '' en un char value déclenchera son comportement de remplissage de blancs tandis que null ne sera pas, donc s'il est important de faire la différence, et je ne vois pas vraiment de raison pour laquelle ce serait le cas, alors vous avez un moyen de le faire.
3. Votre code est porté depuis (ou doit être compatible avec) un autre système qui nécessite un remplissage par des blancs pour des raisons héritées. Dans ce cas, vous êtes coincé avec cela et vous avez ma sympathie.

Il n'y a vraiment aucune raison d'utiliser char simplement parce qu'une certaine longueur est fixe (par exemple, un Y/N flag ou un code de devise ISO tel que 'USD' ). Ce n'est pas plus efficace, cela ne fait pas gagner de place (il n'y a pas d'indicateur de longueur mythique pour un varchar2 , il y a juste une surcharge de remplissage vide pour char ), et cela n'empêche personne d'entrer des valeurs plus courtes. (Si vous saisissez 'ZZ' dans votre char(3) colonne de devise, il sera simplement stocké en tant que 'ZZ ' .) Il n'est même pas rétrocompatible avec une ancienne version d'Oracle qui en dépendait autrefois, car il n'y en a jamais eu.

Et la contagion peut se propager, car (en suivant les meilleures pratiques), vous pouvez ancrer une déclaration de variable en utilisant quelque chose comme sales.currency%type . Maintenant votre l_sale_currency la variable est un char furtif qui sera complété de manière invisible par des blancs pour les valeurs plus courtes (ou '' ), ouvrant la porte à des bugs obscurs où l_sale_currency n'est pas égal à l_refund_currency même si vous avez attribué 'ZZ' à tous les deux.

Certains prétendent que char(n) (où n est une longueur de caractères) indique que les valeurs devraient être n caractères de long, et c'est une forme d'auto-documentation. Mais sûrement si vous êtes sérieux au sujet d'un format à 3 caractères (codes de pays ISO-Alpha-3 plutôt qu'ISO-Alpha-2, par exemple), ne définiriez-vous pas une contrainte pour appliquer la règle, plutôt que de laisser les développeurs jeter un coup d'œil sur un char(3) type de données et tirer leurs propres conclusions ?

CHAR a été introduit dans Oracle 6 pour, j'en suis sûr, des raisons de compatibilité ANSI. Il y a probablement des clients potentiels qui décident du produit de base de données à acheter et de la compatibilité ANSI est sur leur liste de contrôle (ou était à l'époque), et CHAR with blank-padding est défini dans la norme ANSI, donc Oracle doit le fournir. Vous n'êtes pas censé l'utiliser réellement.