À quoi sert le type de données SQL "caractère national" (NCHAR) ?

Question

Ainsi que CHAR (CHARACTER) y VARCHAR (CHARACTER VARYING) SQL offre une NCHAR (NATIONAL CHARACTER) y NVARCHAR (NATIONAL CHARACTER VARYING) type. Dans certaines bases de données, il s'agit du meilleur type de données à utiliser pour les chaînes de caractères (non binaires) :

• Dans SQL Server, NCHAR est stocké en UTF-16LE et constitue le seul moyen de stocker de manière fiable les caractères non ASCII, CHAR étant une page de code à un seul octet seulement ;

• Dans Oracle, NVARCHAR peuvent être stockées en UTF-16 ou UTF-8 plutôt qu'en collation à un seul octet ;

• Mais dans MySQL, NVARCHAR es VARCHAR Les deux types peuvent être stockés avec UTF-8 ou toute autre collation.

Alors, que fait NATIONAL signifie-t-il réellement sur le plan conceptuel, le cas échéant ? Les documents des fournisseurs ne vous informent que sur les jeux de caractères utilisés par leurs propres SGBD, et non sur leur raison d'être. Par ailleurs, la norme SQL92 explique cette fonctionnalité de manière encore moins utile, en indiquant seulement que NATIONAL CHARACTER est stocké dans un jeu de caractères défini par l'implémentation. Contrairement à un simple CHARACTER qui est stocké dans un jeu de caractères défini par l'implémentation. Qui peut être un jeu de caractères différent défini par l'implémentation. Ou pas.

Merci, ANSI. Thansi.

Faut-il utiliser NVARCHAR pour le stockage de tous les caractères (non binaires) ? Existe-t-il des SGBDs actuellement populaires dans lesquels cela fera quelque chose d'indésirable, ou qui ne reconnaissent tout simplement pas le mot-clé (ou l'expression N'' littéraux) ?

Answer 1

"NATIONAL" signifie dans ce cas les caractères spécifiques aux différentes nationalités. Les langues d'Extrême-Orient, en particulier, ont tellement de caractères qu'un octet n'est pas suffisant pour les distinguer tous. Donc si vous avez une application uniquement en anglais (ascii) ou un champ exclusivement anglais vous pouvez vous en sortir en utilisant les anciens types CHAR et VARCHAR, qui ne permettent qu'un octet par caractère.

Cela dit, la plupart du temps, vous devriez utiliser NCHAR/NVARCHAR. Même si vous ne pensez pas avoir besoin de prendre en charge (ou de prendre en charge potentiellement) plusieurs langues dans vos données, même les applications exclusivement anglaises doivent être capables de gérer raisonnablement les attaques de sécurité utilisant des caractères de langues étrangères.

À mon avis, le seul endroit où les anciens types CHAR/VARCHAR sont encore préférables est pour les codes internes et les données en ascii fréquemment référencés sur des plates-formes comme Sql Server qui supportent la distinction - des données qui seraient l'équivalent d'un fichier de type enum dans un langage client comme C++ ou C#.

Answer 2

En revanche, la norme SQL92 explique la fonction de manière encore moins utile, indiquant seulement que la CARACTERE NATIONALE est stocké dans un jeu de caractères de caractères défini par l'implémentation. Par opposition à un simple CHARACTER, qui est stocké dans un jeu de caractères défini par l'implémentation. Qui peut être différent jeu de caractères défini par l'implémentation. Ou pas.

Par coïncidence, c'est la même "distinction" que la norme C++ fait entre char y wchar_t . Une relique de l'âge sombre du codage des caractères, lorsque chaque combinaison de langue et de système d'exploitation avait son propre jeu de caractères.

Doit-on utiliser NVARCHAR pour tout stockage de caractères (non binaires) de stockage de caractères (non binaires) ?

Il n'est pas important que le type déclaré de votre colonne soit VARCHAR o NVARCHAR . Mais il est important d'utiliser Unicode (qu'il s'agisse d'UTF-8, d'UTF-16 ou d'UTF-32) pour le stockage de tous les caractères.

Existe-t-il des SGBDs actuellement populaires dans lesquels dans lequel il fera quelque chose d'indésirable

Oui : Dans MS SQL Server, en utilisant NCHAR fait que vos données (anglaises) prennent deux fois plus d'espace. Malheureusement, UTF-8 n'est pas encore supporté.

EDITAR : SQL Server 2019 enfin introduction du support UTF-8 .

Answer 3

Dans Oracle, le jeu de caractères de la base de données peut être un jeu de caractères multi-octets, de sorte que vous pouvez y stocker toutes sortes de caractères....mais vous devez comprendre et définir la longueur des colonnes de manière appropriée (soit en BYTES, soit en CHARACTERS).

NVARCHAR vous donne la possibilité de disposer d'un jeu de caractères de base de données à un seul octet (ce qui réduit le risque de confusion entre les colonnes de taille BYTE ou CHARACTER) et d'utiliser NVARCHAR comme multioctet. Voir aquí .

Comme je travaille principalement avec des données en anglais, j'opterais pour un jeu de caractères multi-octets (UTF-8 le plus souvent) comme jeu de caractères de la base de données et j'ignorerais NVARCHAR. Si j'héritais d'une ancienne base de données qui était dans un jeu de caractères à un octet et qui était trop volumineuse pour être convertie, je pourrais utiliser NVARCHAR. Mais je préfère ne pas le faire.