Ответ 1

Настоящая причина, по которой вы хотите использовать NVARCHAR, - это когда у вас есть разные языки в одном столбце, вам нужно адресовать столбцы в T-SQL без декодирования, вы хотите видеть данные "изначально" в SSMS, или вы хотите стандартизировать Unicode.

Если вы обрабатываете базу данных как немое хранилище, вполне возможно хранить широкие строки и разные (даже переменные длины) кодировки в VARCHAR (например, UTF-8). Проблема возникает, когда вы пытаетесь кодировать и декодировать, особенно если кодовая страница отличается для разных строк. Это также означает, что SQL Server не сможет легко обрабатывать данные для целей запросов в пределах T-SQL (возможно, измененных) кодированных столбцов.

Использование NVARCHAR позволяет избежать этого.

Я бы порекомендовал NVARCHAR для любого столбца, который будет иметь введенные пользователем данные, которые относительно не ограничены.

Я бы порекомендовал VARCHAR для любого столбца, который является естественным ключом (например, номерной знак транспортного средства, SSN, серийный номер, тег обслуживания, номер заказа, позывной в аэропорту и т.д.) или введенный пользователем, но очень ограниченный (например, телефон номер) или код (ACTIVE/CLOSED, Y/N, M/F, M/S/D/W и т.д.). Нет абсолютно никаких оснований для использования NVARCHAR для них.

Итак, для простого правила:

VARCHAR, когда гарантируется ограничение NVARCHAR в противном случае

Ответ 2

Вы должны использовать NVARCHAR в любое время, когда вам нужно хранить несколько языков. Я считаю, что вы должны использовать его для азиатских языков, но не цитируйте меня.

Здесь проблема, если вы возьмете русский например и сохраните его в varchar, вы будете в порядке, пока вы определяете правильную страницу кода. Но позвольте сказать, что вы используете стандартную английскую sql install, тогда русские символы обрабатываются неправильно. Если вы используете NVARCHAR(), они будут обработаны должным образом.

Изменить

Хорошо позвольте мне процитировать MSDN и maybee Я был конкретным, но вы не хотите хранить больше одной кодовой страницы в varcar, в то время как вы не можете

Когда вы имеете дело с текстовыми данными, которые хранящиеся в char, varchar, varchar (max) или текстовый тип данных, самое важное ограничение для рассмотрения заключается в том, что только информация из одного кодовая страница может быть подтверждена система. (Вы можете хранить данные из несколько кодовых страниц, но это не рекомендуется.) Используемая точная кодовая страница для проверки и хранения данных зависит о сортировке столбца. Если сопоставление на уровне столбцов не было определение, сопоставление базы данных используется. Чтобы определить кодовую страницу который используется для данного столбца, вы можете использовать СОБРАНИЕ ПОМОЩИ функции, как показано ниже примеры кода:

Здесь еще несколько:

Этот пример иллюстрирует тот факт, что многие регионы, такие как грузинский и Хинди, не имеют кодовых страниц, поскольку они являются только Unicode-сопоставлениями. Те сопоставления не подходят для столбцы, в которых используются char, varchar, или текстовый тип данных

Так грузинский или хинди действительно нужно хранить как nvarchar. Арабский также является проблемой:

Другая проблема, с которой вы можете столкнуться, - это невозможность хранения данных, когда нет все персонажи, которые вы хотите поддержка содержится в коде стр. Во многих случаях Windows считает конкретная кодовая страница должна быть "лучшей подгонка", что означает, что есть нет гарантии, что вы можете положиться на кодовая страница для обработки всего текста; это просто лучший доступный. примером этого является арабский script: он поддерживает широкий спектр языков, включая Белуджи, Бербер, Фарси, Кашмирский, Казахский, Киргизский, Пуштунский, Синдхи, Уйгур, Урду и многое другое. Все эти языки имеют дополнительные персонажей за пределами арабского язык, определенный в коде Windows страница 1256. Если вы попытаетесь сохранить эти дополнительные символы в столбец не-Юникод с арабским сопоставление, символы преобразованные в вопросительные знаки.

Что-то, о чем следует помнить, когда вы используете Unicode, хотя вы можете хранить разные языки в одном столбце, вы можете сортировать только один синтаксис. Есть несколько языков, которые используют латинские символы, но не похожи на другие латинские языки. Акценты - хороший пример этого, я не могу вспомнить пример, но был восточно-европейский язык, у которого Y не был похож на английского Y. Тогда есть испанский ч, который испанский пользователь истекает, чтобы сортироваться после h.

В целом все проблемы, с которыми вам приходится иметь дело при работе с интернализацией. По моему мнению, проще всего использовать символы Unicode с самого начала, избегать дополнительных преобразований и снимать пробел. Отсюда мое выражение раньше.

Ответ 3

Греку понадобится UTF-8 для N типов столбцов: αβγ;)

Ответ 4

Джош говорит: "... Что-то, о чем следует помнить, когда вы используете Unicode, хотя вы можете хранить разные языки в одном столбце, вы можете сортировать только с помощью одного сопоставления. Существуют некоторые языки, которые используют латинские символы, но не сортируют, как другие латинские языки Акценты - хороший пример этого, я не могу вспомнить пример, но был восточно-европейский язык, у которого Y не был похож на английского Y. Тогда есть испанский ч, который испанский пользователь expet будет сортироваться после h."

Я родной испанский спикер, а "ch" - это не письмо, а два "c" и "h" и испанский алфавит: abcdefghijklmn - opqrstuvwxyz Мы не ожидаем "ch" после "h", но "i" Алфавит такой же, как на английском языке, за исключением "или" или "HTML" & ntilde; "

Алекс

Ответ 5

TL; DR;
Unicode - (nchar, nvarchar и ntext)
Non-unicode - (char, varchar и текст).

Из MSDN

Коллизии в SQL Server предоставляют правила сортировки, регистр и акцент свойства чувствительности для ваших данных. Коллажи, которые используются с символьные типы данных, такие как char и varchar, диктуют кодовую страницу и соответствующие символы, которые могут быть представлены для этих данных тип.

Предполагая, что вы используете сортировку SQL по умолчанию SQL_Latin1_General_CP1_CI_AS, то следующая script должна распечатать все символы, которые вы можете поместить в VARCHAR, поскольку он использует один байт для хранения одного символа (всего 256), если вы не используете см. его в распечатанном списке - вам нужно NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

Если вы измените настройку, чтобы сказать "японский", вы заметите, что все странные европейские буквы превратились в нормальные, а некоторые символы - на отметки ?.

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

В противном случае сортировка будет странной.