Discussion :

[Ikebukuro]

Salut,

J'avoue que je me prends un peu la tête sur les characters sets d'Oracle et que les noms sont ambiguës .

Il y a deux paramètres, chacun avec NLS au début : NLS_CHARACTERSET (le fameux character set de la base) et NLS_NCHAR_CHARACTERSET.

Est-ce que les deux paramètres servent bien à :
NLS_CHARACTERSET :
-- gère les caractères utilisables dans les noms des objets Oracle que je peux créer (tables, index...)
-- gère les caractères des données que je peux insérer dans mes tables dans les colonnes CHAR, CLOB, VARCHAR2, and LONG

NLS_NCHAR_CHARACTERSET :
-- gère les données qu'on peut insérer dans les colonnes de type NCHAR, NCLOB, and NVARCHAR2

Si le paramètre NLS_NCHAR_CHARACTERSET n'est pas spécifié, il prends alors la valeur du paramètre NLS_CHARACTERSET.


Pour trouver la valeur de ces paramètres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT * FROM database_properties WHERE property_name like '%CHARACTERSET';
PROPERTY_NAME                  PROPERTY_VALUE                 DESCRIPTION
------------------------------ ------------------------------ ------------------------------
NLS_NCHAR_CHARACTERSET         AL16UTF16                      NCHAR Character set
NLS_CHARACTERSET               WE8MSWIN1252                   Character set

[Pomalaix]

Oui !

[Ikebukuro]

Ah, merci pour la réponse, je commençais à douter

[pachot]

C'est tout juste.
Pour l'historique:
La première idée des 'N' datatypes c'était que dans une applis seulement quelques colonnes ont besoin d'un characterset plus universel. Pas besoin de mettre en UTF-8 des noms de tables, des codes types, des numeros de compte,... Et donc on pourrait partir sur du US7ASCII qui simplifie les conversions, comparaisons et tris et mettre toute ce qui est linguistique dans des NCHAR NVARCHAR NCLOB...
Mais personne n'est vraiment parti là dessus à une époque où on réfléchit de moins en moins au design, et d'une autre côté de plus en plus de languages se sont mit à tour gérer en Unicode et donc l'idée aujourd'hui est plutôt de créer des bases en AL32UTF8 et les NCHAR, NVARCHAR2, NCLOB et même les CLOB sont en AL16UTF16.
Du coup on oublie un peu les NVARCHAR2 qui n'ont d'interêt que de gagner de la place lorsqu'on a principalement des caractères non-US7ASCII.

[Ikebukuro]

Franck, tu pourrais préciser ta phrase "du US7ASCII qui simplifie les conversions, comparaisons et tris"?
Je croyais qu'Oracle préconisait de mettre toutes les bases en UTF8 car c'était plus top pour gérer les caractères mais je n'avais pas vu cette dimension performances.

[Waldar]

US7ASCII = 1 octet par caractère, UTFxx de 2 à 4.
Du coup, en temps machine, ça va plus vite de comparer des séquences d'octets plus courtes - et ça occupe moins d'espace sur le disque, en ram, en flash et cetera.

[pachot]

Franck, tu pourrais préciser ta phrase "du US7ASCII qui simplifie les conversions, comparaisons et tris"?
Je croyais qu'Oracle préconisait de mettre toutes les bases en UTF8 car c'était plus top pour gérer les caractères mais je n'avais pas vu cette dimension performances.

Oui, aujourd'hui la recommendation est UTF-8 parce qu'il s'est avéré trop compliqué de décider par colonne.

[Ikebukuro]

US7ASCII = 1 octet par caractère, UTFxx de 2 à 4.
Du coup, en temps machine, ça va plus vite de comparer des séquences d'octets plus courtes - et ça occupe moins d'espace sur le disque, en ram, en flash et cetera.

Attends, en UTF8 TOUS les caractères ont au minimum 2 octets?

Quand je fais un lengthb sur le caractère A, j'ai 1 octet, pas deux. Ou bien c'est sur le stockage qu'on perd de l'espace?
Tu peux approfondir? Par avance merci pour les réponses.

[pachot]

La taille est dans le nom du characterset Oracle:

AL16UTF16 -> de 16 à 16 bits -> 2 octets
AL32UTF8 -> de 8 à 32 bits -> de 1 à 4 octets
WE8MSWIN125 -> 8 bits -> 1 octet
US7ASCII -> 7 bits -> 1 octed

[Ikebukuro]

Franck, si je pouvais mettre 10 pouces verts à ta réponse je le ferais, je n'avais pas compris que les nombres du character set étaient le nombre d'octets