Есть ли причина, по которой я не должен использовать NVARCHAR в Sql Server?

Question

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

Есть ли какая-то причина, почему я должен придерживаться простого varchar? Производительность

Answer 1

В современном мире i18n nvarchar имеет большой смысл. varchar может иметь смысл, чтобы данные, которые указаны , не являлись юникодом (возможно, у вас есть некоторые системные поля, которые должны быть ASCII).

Я бы использовал nvarchar по умолчанию для таких вещей, как имена, описания, адреса и т. Д.

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

Answer 2

Также смотрите этот вопрос: VARCHAR vs производительность NVARCHAR.

Лично я говорю придерживаться varchar (как я ответил в этой теме). Производительность нетривиальна.

Answer 3

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

Коды продуктов не нуждаются в NVarchar - в них не допускается ничего кроме A-Z, 0-9 и "_" ...

Это вдвое больше места для хранения, но также есть только половина записей на страницу индекса (и на страницу данных), а половина кеша памяти «тратится впустую», больше циклов ЦП для сравнения данных и т. Д.

IME обычно используемые иностранные акценты работают только в Varchar (то есть LATIN-1). У нас нет планов делать китайский или другие альтернативные наборы символов, и когда мы сможем обработать этот набор символов с помощью NVarchar с первого дня, это станет наименьшим из наших беспокойств - выравнивание текста справа налево или вертикальное выравнивание текста ?? (

И если вы разрешили NVarchar, скажем, для имени, как вы собираетесь вводить расширенный символ ввода с клавиатуры? И если вы импортируете данные (то есть, это уже NVarchar), как вы сможете искать этого клиента, используя стандартную клавиатуру QWERTY. Много и много связано с интернационализацией приложения, поэтому я считаю, что нет смысла «разрешать это с помощью NVarchar».

Но опять-таки, много мест, где я бываю, чтобы иметь NVarchar ... и большинство столбцов также имеют ширину 50 символов ... они должны знать кое-что о росте населения и планах расширения для почтовых индексов, чего я не знаю! !

Answer 4

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

Если у вас нет планов на использование двухбайтовых наборов символов (т.е. китайских символов), используйте VARCHAR (MAX).

Answer 5

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

Answer 6

Вообще говоря; Начните с самого дорогого типа данных, который имеет наименьшие ограничения. Поместите это в производство. Если производительность начинает вызывать проблемы, выясните, что на самом деле хранится в этих столбцах nvarchar. Есть ли там персонажи, которые не вписываются в varchar? Если нет, переключитесь на varchar. Не пытайтесь предварительно оптимизировать, пока не узнаете, где боль. Я предполагаю, что выбор между nvarchar / varchar - это не то, что замедлит ваше приложение в обозримом будущем. Будут и другие части приложения, где настройка производительности даст вам гораздо больше прибыли.