Напишіть відмінності між варчаром та нварчаром

Зараз ми використовуємо нашу базу даних 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 буде прозоро конвертувати a varcharв nvarchar, тому вам строго не потрібен префікс N для рядкових літералів, якщо ви не використовуєте 2-байтові (тобто Unicode) символи в літералі. Майте в виду , що кастинг nvarcharна varbinaryврожайність різних результатів , ніж робити те ж саме з varchar. Важливим моментом є те, що вам не доведеться одразу змінювати кожен варшар-літерал на nvarchar literal, щоб програма не працювала, що полегшує процес.

* Якщо ви використовуєте стиснення даних (достатньо легкого стиснення рядків, потрібне Enterprise Edition перед SQL Server 2016 SP1 ), ви зазвичай знайдете ncharі nvarcharне займете більше місця, ніж, charі varcharзавдяки компресії Unicode (використовуючи алгоритм SCSU) .

Подумайте, що основні відмінності:

1. Nvarchar зберігає дані UNICODE. Якщо у вас є вимоги зберігати UNICODE або багатомовні дані, вибір - nvarchar. Varchar зберігає дані ASCII і повинен бути вашим типом даних для нормального використання.
2. Щодо використання пам'яті, nvarchar використовує 2 байти на символ, тоді як varchar використовує 1.
3. ПРИЄДНАЙТЕСЬ ВАРХАР до 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, ви збільшуєте сховище для DB, резервних копій (локальних і поза межами). Сучасні бази даних повинні підтримувати обидва, і будь-які звернення Конверсії повинні враховуватися в дизайні.