Qu'entend-on par nvarchar
?
Quelle est la différence entre char
, nchar
, varchar
et nvarchar
dans SQL Server?
Qu'entend-on par nvarchar
?
Quelle est la différence entre char
, nchar
, varchar
et nvarchar
dans SQL Server?
Réponses:
Juste pour éclaircir ... ou résumer ...
nchar
et nvarchar
peut stocker des caractères Unicode .char
et ne peut pas stocker de caractères Unicode .varchar
char
et nchar
sont de longueur fixe qui réservent de l'espace de stockage pour le nombre de caractères que vous spécifiez même si vous n'utilisez pas tout cet espace.varchar
et nvarchar
sont de longueur variable qui n'utilisera que des espaces pour les personnages que vous stockez. Il ne réservera pas de stockage comme char
ounchar
.nchar
et nvarchar
occupera deux fois plus d'espace de stockage, il peut donc être judicieux de les utiliser uniquement si vous avez besoin de la prise en charge Unicode .
n...
versions occupent ou non deux fois plus d'espace de stockage que ma réponse le montre
Jusqu'à présent, toutes les réponses indiquent qu'il varchar
s'agit d'un octet simple, d' nvarchar
un octet double. La première partie de cela dépend en fait du classement comme illustré ci-dessous.
DECLARE @T TABLE
(
C1 VARCHAR(20) COLLATE Chinese_Traditional_Stroke_Order_100_CS_AS_KS_WS,
C2 NVARCHAR(20)COLLATE Chinese_Traditional_Stroke_Order_100_CS_AS_KS_WS
)
INSERT INTO @T
VALUES (N'中华人民共和国',N'中华人民共和国'),
(N'abc',N'abc');
SELECT C1,
C2,
LEN(C1) AS [LEN(C1)],
DATALENGTH(C1) AS [DATALENGTH(C1)],
LEN(C2) AS [LEN(C2)],
DATALENGTH(C2) AS [DATALENGTH(C2)]
FROM @T
Retour
Notez que les caractères 华
et 国
n'étaient toujours pas représentés dans la VARCHAR
version et ont été remplacés silencieusement par ?
.
Il n'y a en fait toujours aucun caractère chinois qui puisse être représenté par un seul octet dans ce classement. Les seuls caractères à un octet sont l'ensemble ASCII occidental typique.
De ce fait, il est possible qu'un insert d'une nvarchar(X)
colonne à une varchar(X)
colonne échoue avec une erreur de troncature (où X désigne un nombre identique dans les deux cas).
SQL Server 2012 ajoute des classements SC (caractère supplémentaire) qui prennent en charge UTF-16
. Dans ces classements, un seul nvarchar
caractère peut prendre 2 ou 4 octets.
nchar et char fonctionnent à peu près de la même manière l'un que l'autre, tout comme nvarchar et varchar. La seule différence entre eux est que nchar / nvarchar stocke les caractères Unicode (essentiel si vous avez besoin d'utiliser des jeux de caractères étendus) tandis que varchar ne le fait pas.
Étant donné que les caractères Unicode nécessitent plus de stockage, les champs nchar / nvarchar prennent deux fois plus d'espace (par exemple, dans les versions antérieures de SQL Server, la taille maximale d'un champ nvarchar est de 4000).
Cette question est un double de celle-ci .
Juste pour ajouter quelque chose de plus: nchar - ajoute des espaces de fin aux données. nvarchar - n'ajoute pas d'espaces de fin aux données.
Donc, si vous allez filtrer votre jeu de données par un champ 'nchar', vous pouvez utiliser RTRIM pour supprimer les espaces. Par exemple, le champ nchar (10) appelé BRAND stocke le mot NIKE. Il ajoute 6 espaces à droite du mot. Ainsi, lors du filtrage, l'expression doit se lire: RTRIM (Fields! BRAND.Value) = "NIKE"
J'espère que cela aide quelqu'un là-bas parce que je me débattais avec ça un peu tout à l'heure!
Ma tentative de résumer et de corriger les réponses existantes:
Tout d'abord, char
et nchar
utilisera toujours une quantité fixe d'espace de stockage, même lorsque la chaîne à stocker est plus petite que l'espace disponible, tandis que varchar
et nvarchar
utilisera uniquement autant d'espace de stockage que nécessaire pour stocker cette chaîne (plus deux octets de surcharge, probablement pour stocker la longueur de la chaîne). N'oubliez donc pas que "var" signifie "variable", comme dans l'espace variable.
Le deuxième point important à comprendre est que, nchar
et nvarchar
stockez les chaînes en utilisant exactement deux octets par caractère, tandis que char
et varchar
utilisez un codage déterminé par la page de code de classement, qui sera généralement exactement un octet par caractère (bien qu'il y ait des exceptions, voir ci-dessous). En utilisant deux octets par caractère, une très large gamme de caractères peut être stockée, donc la chose de base à retenir ici est cela nchar
et a nvarchar
tendance à être un bien meilleur choix lorsque vous souhaitez une prise en charge de l'internationalisation, ce que vous faites probablement.
Maintenant pour quelques points plus fins.
Tout d' abord, nchar
et des nvarchar
colonnes toujours stocker des données en utilisant UCS-2. Cela signifie qu'exactement deux octets par caractère seront utilisés, et tout caractère Unicode dans le plan multilingue de base (BMP) peut être stocké par un champ nchar
ou nvarchar
. Cependant, il n'est pas possible que n'importe quel caractère Unicode puisse être stocké. Par exemple, selon Wikipedia, les points de code pour les hiéroglyphes égyptiens ne relèvent pas du BMP. Il existe donc des chaînes Unicode qui peuvent être représentées en UTF-8 et d'autres vrais encodages Unicode qui ne peuvent pas être stockés dans un serveur nchar
ou un nvarchar
champ SQL , et des chaînes écrites en hiéroglyphes égyptiens en feraient partie. Heureusement, vos utilisateurs n'écrivent probablement pas dans ce script, mais c'est quelque chose à garder à l'esprit!
Une autre source de confusion , mais le point intéressant que d' autres affiches ont mis en évidence que char
et les varchar
champs peuvent utiliser deux octets par caractère pour certains caractères si la page de code de classement exige. (Martin Smith donne un excellent exemple dans lequel il montre comment Chinese_Traditional_Stroke_Order_100_CS_AS_KS_WS présente ce comportement. Vérifiez-le.)
MISE À JOUR: Depuis SQL Server 2012, il existe enfin des pages de codes pour UTF-16 , par exemple Latin1_General_100_CI_AS_SC, qui peuvent vraiment couvrir toute la plage Unicode.
char
: données de caractères de longueur fixe avec une longueur maximale de 8000 caractères.nchar
: données unicode de longueur fixe avec une longueur maximale de 4000 caractères.Char
= Longueur 8 bitsNChar
= Longueur de 16 bitschar
ne pouvait pas avoir une longueur de 8 bits. Il n'a pas besoin de stocker la longueur et la longueur fixe peut contenir jusqu'à 8 000 caractères.
nchar[(n)]
(caractère national)
n
définit la longueur de la chaîne et doit être une valeur comprise entre 1 et 4 000.n
octets.nvarchar [(n | max)]
(caractère national variable.)
n
définit la longueur de la chaîne et peut être une valeur comprise entre 1 et 4 000.max
indique que la taille de stockage maximale est de 2 ^ 31-1 octets (2 Go).char [(n)]
(personnage)
non-Unicode
Données de chaîne de longueur fixe .n
définit la longueur de la chaîne et doit être une valeur comprise entre 1 et 8 000.n
octets.varchar [(n | max)]
(caractère variable)
n
définit la longueur de la chaîne et peut être une valeur comprise entre 1 et 8 000.max
indique que la taille de stockage maximale est de 2 ^ 31-1 octets (2 Go).Les différences sont les suivantes:
Une autre différence est la longueur. Nchar et nvarchar peuvent contenir jusqu'à 4 000 caractères. Et char et varchar peuvent contenir jusqu'à 8 000 caractères. Mais pour SQL Server, vous pouvez également utiliser un [n] varchar (max) qui peut gérer jusqu'à 2 147 483 648 caractères. (Deux gigaoctets, un entier signé de 4 octets.)
nchar nécessite plus d'espace que nvarchar.
par exemple,
Un nchar (100) stockera toujours 100 caractères même si vous n'en saisissez que 5, les 95 caractères restants seront remplis d'espaces. Stocker 5 caractères dans un nvarchar (100) économisera 5 caractères.
nchar (10) est une chaîne Unicode de longueur fixe de longueur 10. nvarchar (10) est une chaîne Unicode de longueur variable avec une longueur maximale de 10. En règle générale, vous utiliseriez la première si toutes les valeurs de données sont de 10 caractères et la seconde si les longueurs varient.
nchar est de longueur fixe et peut contenir des caractères unicode. il utilise deux octets de stockage par caractère.
varchar est de longueur variable et ne peut pas contenir de caractères unicode. il utilise un stockage d'octets par caractère.
UCS-2
(qui se trouve être le codage utilisé par SQL Server) stocke tous les caractères dans exactement deux octets, voir msdn.microsoft.com/en-us/library/bb330962%28v=sql.90%29.aspx : SQL Server stores Unicode in the UCS-2 encoding scheme... UCS-2 is a fixed-length encoding that represents all characters as a 16-bit value (2 bytes)
. SQL Server 2008 peut utiliser la compression SCSU, mais est toujours la compression des chaînes Unicode codées UCS-2: msdn.microsoft.com/en-us/library/ee240835.aspx
NVARCHAR peut stocker des caractères Unicode et prend 2 octets par caractère.
nvarchar
prend toujours 2 octets par caractère.