В чем разница между char, nchar, varchar и nvarchar в SQL Server?

nchar и char почти так же работают друг с другом, как nvarchar и varchar. Единственное различие между ними заключается в том, что nchar / nvarchar хранят символы Unicode (что необходимо, если вам требуется использование расширенных наборов символов), а varchar - нет.

Поскольку для символов Юникода требуется больше места для хранения, поля nchar / nvarchar занимают вдвое больше места (так, например, в более ранних версиях SQL Server максимальный размер поля nvarchar составляет 4000).

Этот вопрос дублирует Вот этот.

nchar (10) - это строка Unicode фиксированной длины длиной 10. nvarchar (10) - строка Unicode переменной длины с максимальной длиной 10. Как правило, вы должны использовать первую строку, если все значения данных составляют 10 символов, а последнюю. если длина различается.

NVARCHAR может хранить символы Unicode и занимает 2 байта на символ.

• nchar имеет фиксированную длину и может содержать символы Юникода. он использует два байта памяти для каждого символа.

• varchar имеет переменную длину и не может содержать символы Юникода. для каждого символа используется один байт памяти.

Просто чтобы прояснить ... или подвести итог ...

• nchar и nvarchar могут хранить символы Юникод.
• Символы char и varcharне может хранить Unicode.
• char и nchar - это фиксированная длина, который будет зарезервировать место для хранения для количества символов, которое вы укажете, даже если вы не используете все это пространство.
• varchar и nvarchar - это переменная длина, которые будут использовать пробелы только для хранимых вами символов. Это не резервирует хранилище, например char или nchar.

nchar и nvarchar будут занимать вдвое больше места для хранения, поэтому может быть разумно использовать их только в том случае, если вам нужна поддержка Юникод.

nchar требует больше места чем nvarchar.

например,

Nchar (100) всегда будет хранить 100 символов, даже если вы введете только 5, оставшиеся 95 символов будут дополнены пробелами. Сохранение 5 символов в nvarchar (100) сэкономит 5 символов.

• char: символьные данные фиксированной длины с максимальной длиной 8000 символов.
• nchar: данные Unicode фиксированной длины с максимальной длиной 4000 символов.
• Char = длина 8 бит
• NChar = длина 16 бит

Различия - это:

1. n [var] char хранит Unicode, а [var] char хранит только однобайтовые символы.
2. [n] char требует фиксированного количества символов точной длины, в то время как [n] varchar принимает переменное количество символов до определенной длины включительно.

Еще одно отличие - длина. И nchar, и nvarchar могут иметь длину до 4000 символов. И char и varchar могут быть длиной до 8000 символов. Но для SQL Server вы также можете использовать [n] varchar (max), который может обрабатывать до 2 147 483 648 символов. (Два гигабайта, 4-байтовое целое число со знаком.)

Просто чтобы добавить еще: нчар - добавляет конечные пробелы к данным. nvarchar - не добавляет конечные пробелы к данным.

Итак, если вы собираетесь фильтровать свой набор данных по полю nchar, вы можете использовать RTRIM для удаления пробелов. Например. В поле nchar (10) с именем BRAND хранится слово NIKE. Он добавляет 6 пробелов справа от слова. Итак, при фильтрации выражение должно читать: RTRIM (Fields! BRAND.Value) = "NIKE"

Надеюсь, это поможет кому-то там, потому что я только что немного боролся с этим!

Все ответы на данный момент указывают, что varchar - однобайтный, nvarchar - двухбайтный. Первая часть этого на самом деле зависит от сопоставления, как показано ниже.

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  

Возврат

Обратите внимание, что символы 华 и 国 все еще не были представлены в версии VARCHAR и были незаметно заменены на ?.

На самом деле все еще нет китайских иероглифов, которые можно было бы представить одним байтом в этом сопоставлении. Единственные однобайтовые символы - это типичный западный набор ASCII.

Из-за этого возможна вставка из столбца nvarchar(X) в столбец varchar(X)выйти из строя с ошибкой усечения (где X обозначает число, одинаковое в обоих случаях).

SQL Server 2012 добавляет параметры сортировки SC (дополнительные символы), которые поддерживают UTF-16. В этих сопоставлениях один символ nvarchar может занимать 2 или 4 байта.

Моя попытка обобщить и исправить существующие ответы:

Во-первых, char и nchar всегда будут использовать фиксированный объем дискового пространства, даже если строка, которую нужно сохранить, меньше доступного пространства, тогда как varchar и nvarchar будут использовать только столько дискового пространства, сколько необходимо для хранения этой строки (плюс два байтов накладных расходов, предположительно для хранения длины строки). Так что помните, что «var» означает «переменная», как в пространстве переменных.

Второй важный момент, который следует понять, заключается в том, что nchar и nvarchar хранят строки с использованием точно по два байта на символ, тогда как char и varchar используют кодировку, определяемую кодовой страницей сопоставления, которая будет как правило ровно одним байтом на символ (хотя есть исключения, см. ниже). Используя два байта на символ, можно сохранить очень широкий диапазон символов, поэтому важно помнить, что nchar и nvarchar, как правило, являются гораздо лучшим выбором, когда вам нужна поддержка интернационализации, что вы, вероятно, и делаете.

Теперь о некоторых тонкостях.

Во-первых, столбцы всегдаnchar и nvarchar хранят данные с использованием UCS-2. Это означает, что будет использоваться ровно два байта на символ, и любой символ Unicode в базовой многоязычной плоскости (BMP) может быть сохранен в поле nchar или nvarchar. Однако это не тот случай, когда символ Unicode Любые может быть сохранен. Например, согласно Википедии, кодовые точки египетских иероглифов находятся за пределами BMP. Следовательно, есть строки Unicode, которые могут быть представлены в UTF-8 и других истинных кодировках Unicode, которые не могут быть сохранены в поле SQL Server nchar или nvarchar, и среди них будут строки, написанные египетскими иероглифами. К счастью, ваши пользователи, вероятно, не пишут в этом сценарии, но об этом следует помнить!

Другой сбивающий с толку, но интересный момент, который подчеркнули другие плакаты, заключается в том, что поля char и varchar могут использовать два байта на символ для определенных символов, если этого требует кодовая страница сопоставления. (Мартин Смит приводит отличный пример, в котором он показывает, как Chinese_Traditional_Stroke_Order_100_CS_AS_KS_WS демонстрирует такое поведение. Проверьте это.)

Обновлено: Начиная с SQL Server 2012, наконец, есть кодовые страницы для UTF-16, например Latin1_General_100_CI_AS_SC, который действительно может охватывать весь диапазон Unicode.

nchar[(n)] (национальный символ)

• Строковые данные фиксированной длины Юникод.
• n определяет длину строки и должен иметь значение от 1 до 4000.
• Размер хранилища в два раза больше n байт.

nvarchar [(n | max)] (национальные символы меняются.)

• Строковые данные переменной длины Юникод.
• n определяет длину строки и может принимать значения от 1 до 4000.
• max указывает, что максимальный размер хранилища составляет 2 ^ 31-1 байта (2 ГБ).
• Размер хранилища в байтах в два раза превышает фактическую длину введенных данных + 2 байта.

char [(n)] (персонаж)

• Строковые данные non-Unicode фиксированной длины.
• n определяет длину строки и должен иметь значение от 1 до 8000.
• Размер хранилища составляет n байт.

varchar [(n | max)] (изменение символа)

• Строковые данные переменной длины, не-Юникод.
• n определяет длину строки и может принимать значения от 1 до 8000.
• max указывает, что максимальный размер хранилища составляет 2 ^ 31-1 байта (2 ГБ).
• Размер хранилища - это фактическая длина введенных данных + 2 байта.