Неважно, какой размер nvarchar?

Ответ 1

Согласно документации:

nvarchar [(n | max)]

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

Таким образом, при вычислении размера хранилища имеет значение только фактическая длина введенных данных.

В документации не сказано, почему она существует, но параметр длины полезен, потому что он применяет простые ограничения ограничения (например, поэтому кто-то не может ввести 2 ГБ текста в качестве своего "имени" ).

Ответ 2

Причина, по которой вам не нужно использовать nvarchar (1000), когда вам нужно nvarchar (10), заключается в предотвращении ввода в базу данных с плохими данными. Если вам это не нравится, когда в телефонных номерах говорят такие вещи, как "называть толстую секретаршу не милой, если вы хотите получить реальный ответ" (не такой случайный пример, который я когда-то нашел в фактическом файле клиента, отправленном нам). Пользователи быстро разойдутся какие поля достаточно велики, чтобы они могли использовать их для хранения заметок, в которых, как правило, бесполезно делать данные в поле.

А что касается nvarchar (Max), это плохая идея использовать это вообще, если вы не ожидаете иметь более 4000 символов. Посмотрите индексацию и varchar (max), чтобы понять, почему.

Ответ 3

Что касается размера и производительности, помните, что SQL-сервер сохранит начальное значение данных для nvarchar/varchar и всего значения для nchar/char с точки зрения пространства. Например: nvarchar(1000) с сохраненными данными test data будет изначально занимать 9 * 2 байта пробела или 18-байтов. В то время как nchar(1000) будет принимать 1000 * 2 байта (2000 байт) независимо от того, что.

Затем он продолжает веселиться, добавляя следующий набор данных на странице (это 8k), пока страница не встретит (или близко) набор заполняющих факторов для таблицы. Затем начинается новая страница. Теперь позвольте сказать, что пользователю нужно обновить эти данные и ввести что-то с каким-то веществом в предыдущем поле, скажем, примерно 800 символов. Теперь эта ценность нуждается в обновлении и будет значительно расти, но теперь страница заполнена, и когда данные для этого поля будут расти, страница должна разделиться и сделать путь для данных (если коэффициент заполнения не будет достаточно низким, чтобы рост).

Эта разбивка страницы будет агрегироваться как фрагментация индекса и приведет к более медленному времени поиска/поиска и увеличению времени обновления. Таким образом, может быть разница в отношении воздействия на производительность, если данные значительно меняются.

Как это часто бывает, ответ: "зависит".

Ответ 4

Так как nvarchar - это тип данных переменной длины, он будет хранить только данные, которые вы ему назначили (2 байта на char) плюс 2 байта для информации о длине, и в основном используется для двухбайтовых языков, таких как китайский.

Лично я использую varchar (n), когда знаю некоторое ограничение (т.е. ограничение строки запроса URL-адреса, ограничение на ограничение доступа к файлам или собственный лимит). Я использую varchar (max), когда максимальная длина undefined и может превышать 8000 символов. И я почти никогда не использую nvarchar в первую очередь потому, что наше приложение никогда не станет международным.

Ответ 5

По крайней мере, в базе данных SQL Server не разрешено создавать уникальное ограничение для столбца с его типом как nvarchar (max). Он должен быть ограничен nvarchar (450), чтобы успешно добавить это ограничение.

Ответ 6

Да, это имеет значение с точки зрения производительности.

Оптимизатор запросов просматривает эти метаданные для планирования запроса.. Он оценивает размер строки на основе предоставленной длины, и это может вызвать проблемы с производительностью. Например, когда вам нужно отсортировать столбец, который является varchar (10), он может планировать запуск операции сортировки в ОЗУ, но тот же запрос для varchar (1000) может планироваться для запуска на вторичном хранилище.

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

Я узнал об этом из этого сообщения в блоге (я не автор): http://aboutsqlserver.com/2010/08/18/what-is-the-optimal-size-for-variable-width-columns/

ПРИМЕЧАНИЕ. Не выбирайте меньшую длину вслепую. Изменение размера поля может стать большой головной болью обслуживания. Я помню, когда я выбирал небольшую длину для поля LastName, и некоторые пользователи не могли зарегистрироваться в системе из-за этого. Мы должны были обновить критическую базу данных в использовании (требуется время для увеличения длины поля), а также скомпилировать программу и перераспределить ее. Если бы я выбрал правильный размер поля, я мог бы избежать всех этих головных болей.

Вы также можете прочитать о различиях между nvarchar (max) и nvarchar (n), поскольку n > 4000 для 4000 делает поле в основном похожим на nvarchar (max). (Есть ли недостатки в использовании nvarchar (MAX)?)