Ограничение размера NVARCHAR в SQLServer?

Question

Мне было интересно, каковы будут последствия установки для полей NVARCHAR значения MAX вместо определенного размера в SQL Server 2008 и ограничения ввода логики приложения. Кроме того, это будет плохая практика проектирования?

Answer 1

NVARCHAR (MAX) намного лучше работает с данными меньшего размера, чем старый тип данных NTEXT, однако NVARCHAR (n) всегда будет более эффективен в некоторых областях.

Как правило, использование типа данных, который наилучшим образом представляет данные, которые вы храните, почти всегда является наилучшей практикой.

Answer 2

Существует множество последствий для производительности . В частности, в скалярном UDF общего назначения с заполнением строк я заметил огромные различия в производительности, когда выходные данные были объявлены как VARCHAR (MAX), даже если входные данные никогда не превышали> 40 символов. Переход на VARCHAR (50) произвел ОГРОМНОЕ улучшение.

Answer 3

Просто для того, чтобы дополнить все остальные ответы: будьте осторожны со сценариями, в которых данные могут поступать из других источников, например - в качестве примера - текстовые файлы, импортированные извне ваших приложений; это может обойти любую логику приложения, если вы не продублируете ее в подпрограммах импорта ...

Answer 4

Не следует устанавливать для всех полей значение NVARCHAR (MAX), если вы знаете, что они никогда не будут содержать более конечного числа символов из-за способа, которым SQL хранит данные такого типа - данные, достаточно малые для размещения на странице хранится на странице, но когда он становится слишком большим, он будет удален со страницы и будет храниться отдельно.

Кроме того, вы уверены, что вам нужен NVARCHAR, поскольку он хранит данные Unicode, которые занимают вдвое больше места по сравнению со стандартным VARCHAR? Если вы знаете , вы будете использовать стандартные символы, тогда используйте VARCHAR.

Slo, подумайте об использовании вашего приложения. Если у вас есть поле адреса, которое не имеет теоретических ограничений по размеру, как бы вы напечатали его на конверте? Вы говорите, что реализуете логику в приложении переднего плана, но зачем все же разрешать базе данных иметь слишком большие данные? И что произойдет, если данные попадут в базу данных, что нарушит логику вашего интерфейса?

Answer 5

Основным недостатком является то, что NVARCHAR(MAX) нельзя индексировать обычными индексами.

Кроме того, существуют некоторые проблемы с переменными типа NVARCHAR(MAX) и с производительностью функций, анализирующих эти переменные.

Если вы просто хотите хранить и извлекать данные как есть, а не анализировать их на стороне SQL Server, тогда NVARCHAR(MAX) - это хорошо.

Answer 6

Установка предела имеет побочный эффект некоторой проверки максимальной длины