Напишите различия между varchar и nvarchar

В настоящее время мы используем нашу базу данных SQL Server 2012 varchar, и мы хотели бы изменить это nvarchar. Я создал скрипт для этого.

Мой вопрос: есть ли различия в том, как SQL Server пишет в varcharстолбцы по сравнению со nvarcharстолбцами? У нас есть ряд внутренних процедур, которые меня беспокоят.

Редактировать:
Не уверен, что это помогает, но столбцы не имеют индексов, f / k или ограничений на них.

Вы должны быть уверены, что префикс строковых литералов Unicode имеет префикс N. Например, они будут работать по-другому, если базовый тип данных NVARCHAR:

CREATE TABLE dbo.t(c NVARCHAR(32));

INSERT dbo.t(c) SELECT 'រៀន';
INSERT dbo.t(c) SELECT 'នរៀ';
INSERT dbo.t(c) SELECT N'រៀន';

SELECT c FROM dbo.t;

SELECT c FROM dbo.t WHERE c = 'រៀន';
SELECT c FROM dbo.t WHERE c = N'រៀន';

Результаты:

c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!

c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?

c
----
រៀន

Для тех, кто работает на мобильных устройствах или в дряхлых браузерах, в которых вместо стандартных символов Unicode отображаются прямоугольники, это выглядит так:

Самая большая проблема заключается в том, что nvarcharиспользуется 2 байта на символ, тогда как varcharиспользуется 1. Таким образом, nvarchar(4000)используется тот же объем памяти, что и varchar(8000)*.

В дополнение ко всем вашим данным персонажей, требующим вдвое больше места для хранения, это также означает:

• Возможно, вам придется использовать более короткие nvarcharстолбцы, чтобы сохранить строки в пределах 8060 байт / 8000 байт.
• Если вы используете nvarchar(max)столбцы, они будут вытеснены из строки раньше, чем varchar(max)будут.
• Возможно, вам придется использовать более короткие nvarcharстолбцы, чтобы остаться в пределах ограничения на индексный ключ в 900 байт (я не знаю, почему вы захотите использовать такой большой индексный ключ, но вы никогда не знаете).

Кроме того, работа с nvarcharне сильно отличается, если предположить, что ваше клиентское программное обеспечение построено для обработки Unicode. SQL Server будет прозрачно реконвертирование varcharк nvarchar, поэтому строго не нужен N префикса для строковых литералов , если вы не используете 2-байты (т.е. Unicode) символы в буквальном. Имейте nvarcharв varbinaryвиду, что приведение к дает другие результаты, чем при том же varchar. Важным моментом является то, что вам не нужно сразу менять каждый литерал varchar на литерал nvarchar, чтобы приложение работало, что помогает упростить процесс.

* Если вы используете сжатие данных (достаточно простого сжатия строк, требуется Enterprise Edition до SQL Server 2016 с пакетом обновления 1 ), вы, как правило, находите ncharи nvarcharзанимает не больше места, чем charи varcharиз-за сжатия Unicode (с использованием алгоритма SCSU) .

Подумайте о следующих основных различиях:

1. Nvarchar хранит данные UNICODE. Если у вас есть требования для хранения UNICODE или многоязычных данных, nvarchar - выбор. Varchar хранит данные ASCII и должен быть вашим типом данных, выбранным для обычного использования.
2. Что касается использования памяти, nvarchar использует 2 байта на символ, тогда как varchar использует 1.
3. Присоединение VARCHAR к NVARCHAR значительно повысило производительность.
4. Может потребоваться префикс N при вставке данных: INSERT dbo.t (c) SELECT N'ʤ ʥ ʦ ʧ ʨ ';
5. Некоторые эксперты рекомендуют nvarchar всегда, потому что: поскольку все современные операционные системы и платформы разработки используют Unicode для внутреннего использования, используя nvarchar, а не varchar, будут избегать преобразования кодирования при каждом чтении или записи в базу данных.

nvarchar был необходим для репликации слиянием RDP из мобильной базы данных в SQL Server 2005. Также использовались LTrim (), RTrim () и Trim (), bc nvarchar не автоматически обрезал () пробелы от ввода данных, тогда как Varchar делал ,

Я не знаю, изменилось ли это в последние годы или нет, но теперь nvarchar - это стандарт, используемый для входа на сайт .NET Simple Membership на VS Pro 2017, который используется в созданной базе данных.

Если вы используете NVarchar поверх Varchar и у вас нет требований поддерживать MULTI-LINQUAL, вы увеличиваете объем хранилища для БД, резервных копий (локальных и внешних). Современные базы данных должны поддерживать оба варианта, и в проекте должны учитываться любые совпадения конверсий.