Réponses:
Supposons que le jeu de caractères de la base de données soit UTF-8, qui est le paramètre recommandé dans les versions récentes d'Oracle. Dans ce cas, certains caractères nécessitent plus d'un octet pour être stockés dans la base de données.
Si vous définissez le champ comme VARCHAR2(11 BYTE)
, Oracle peut utiliser jusqu'à 11 octets pour le stockage, mais vous ne pourrez peut-être pas stocker 11 caractères dans le champ, car certains d'entre eux prennent plus d'un octet à stocker, par exemple des caractères non anglais.
En définissant le champ comme VARCHAR2(11 CHAR)
vous le dites à Oracle, il peut utiliser suffisamment d'espace pour stocker 11 caractères, quel que soit le nombre d'octets nécessaires pour stocker chacun d'eux. Un seul caractère peut nécessiter jusqu'à 4 octets.
L'un a exactement l'espace pour 11 octets, l'autre pour exactement 11 caractères. Certains jeux de caractères tels que les variantes Unicode peuvent utiliser plus d'un octet par caractère, par conséquent, le champ de 11 octets peut avoir de l'espace pour moins de 11 caractères en fonction du codage.
Voir également http://www.joelonsoftware.com/articles/Unicode.html
En fonction de la configuration du système, la taille de CHAR mesurée en BYTES peut varier. Dans vos exemples:
Je ne suis pas sûr car je ne suis pas un utilisateur Oracle, mais je suppose que la différence réside lorsque vous utilisez des jeux de caractères multi-octets tels que Unicode (UTF-16/32). Dans ce cas, 11 octets peuvent représenter moins de 11 caractères.
De plus, ces types de champs peuvent être traités différemment en ce qui concerne les caractères accentués ou la casse, par exemple 'binaryField (ete) = "été"' ne correspondra pas alors que 'charField (ete) = "été"' pourrait (encore une fois pas sûr d'Oracle) .
VARCHAR2
. Déclarer aVARCHAR2(4000 CHAR)
autorisera moins de 4000 caractères si certains des caractères nécessitent plusieurs octets de stockage.