Там какие-либо недостатки к всегда использованию nvarchar (МАКС)?

Это заставит экран разработать тяжелее, поскольку Вы больше не будете в состоянии предсказать, насколько широкий Ваши средства управления должны быть.

Это вызовет проблему производительности, хотя она никогда не может вызывать фактические проблемы, если Ваша база данных является маленькой. Каждая запись займет больше места на жестком диске, и база данных должна будет считать больше секторов диска при поиске большого количества записей сразу. Например, маленькая запись могла соответствовать 50 к сектору, и большая запись могла соответствовать 5. Необходимо было бы считать в 10 раз больше данных из диска с помощью большой записи.

Интересная ссылка: , Почему использование VARCHAR, когда можно использовать ТЕКСТ?

Это о PostgreSQL и MySQL, таким образом, анализ производительности отличается, но логика для "явности" все еще содержит: Почему сила самостоятельно, чтобы всегда волноваться о чем-то это релевантно небольшой процент времени? При сохранении адреса электронной почты к переменной Вы использовали бы 'строку' не 'строка, ограниченная 80 символами'.

Единственная проблема, которую я нашел, состояла в том, что мы разрабатываем наши приложения на SQL Server 2005, и в одном экземпляре, мы должны поддерживать SQL Server 2000. Я просто учился, твердый путь , что SQL Server 2000 не нравится МАКС. опция за varchar или nvarchar.

У меня был udf, какие строки заполнения и помещал вывод в varchar (макс.). Если это использовалось непосредственно вместо того, чтобы вспомнить соответствующий размер для скорректированного столбца, производительность была очень плоха. Я закончил тем, что поместил udf в произвольную длину с большим примечанием вместо того, чтобы полагаться на все вызывающие стороны udf для переделывания строки к меньшему размеру.

Это - справедливый вопрос, и он действительно заявлял кроме obvious†¦

, Недостатки могли включать:

Оптимизатор запросов последствий Производительности использует размер поля для определения большей части efficent exectution план

"1. Выделение пространства в расширяется, и страницы базы данных гибки. Таким образом при добавлении информации к полю с помощью обновления, база данных должна была бы создать указатель, если новые данные более длинны, чем вставленное предыдущее. Это файлы базы данных стали бы фрагментированными = более низкая производительность в почти всем, от индекса, чтобы удалить, обновить и вставляют". http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

последствия Интеграции - трудный для других систем знать, как интегрировать с Вашим ростом базы данных Unpredictable данных Возможные проблемы безопасности, например, Вы могли разрушить систему путем приведения в рабочее состояние всего дискового пространства

здесь существует хорошая статья: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

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

Механизм базы данных является гораздо эффективнее хранить все в хранилище BLOB-объектов. Чем меньше вы можете ограничить строку, тем лучше. Чем больше строк вы сможете втиснуть на страницу, тем лучше. База данных работает лучше, когда ей требуется доступ к меньшему количеству страниц.

Поддержка устаревшей системы. Если у вас есть система, которая использует данные, и ожидается, что она будет определенной длины, то база данных - хорошее место для обеспечения длины. Это не идеально, но устаревшие системы иногда не идеальны. = P

Задача базы данных - хранить данные, чтобы их могло использовать предприятие. Частью того, чтобы сделать эти данные полезными, является их значимость. Разрешение кому-либо вводить неограниченное количество символов для своего имени не гарантирует значимых данных.

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

Плохая идея, когда вы знаете, что поле будет в заданном диапазоне - например, от 5 до 10 символов. Думаю, я бы использовал max, только если не был уверен, какой будет длина. Например, телефонный номер никогда не будет содержать больше определенного количества символов.

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

Я все же понимаю вашу точку зрения - там некоторые поля я бы определенно рассмотрел с использованием varchar (max).

Интересно, что документы MSDN суммируют это довольно хорошо:

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

Здесь есть интересное обсуждение этой проблемы .

Причина, по которой НЕ следует использовать макс. Или текстовые поля, заключается в том, что вы не можете выполнять онлайн-индекс перестраивается , т. Е. ПЕРЕСТРОЙКА С ONLINE = ON даже с SQL Server Enterprise Edition.

Считайте это просто еще одним уровнем безопасности. Вы можете спроектировать свою таблицу без отношений внешнего ключа - что совершенно корректно - и обеспечить существование связанных сущностей полностью на бизнес-уровне. Однако внешние ключи считаются хорошей практикой проектирования, поскольку они добавляют еще один уровень ограничений на случай, если что-то не так на бизнес-уровне. То же самое касается ограничения размера поля и без использования varchar MAX.

Одна из проблем заключается в том, что если вам приходится работать с несколькими версиями SQL Server, MAX не всегда будет работать. Поэтому, если вы работаете с устаревшими БД или в любой другой ситуации, которая включает несколько версий, вам лучше быть очень осторожными.

Иногда вам нужно, чтобы тип данных придавал некоторый смысл данным в нем.

Скажем, например, у вас есть столбец, длина которого на самом деле не должна превышать, скажем, 20 символов. Если вы определите этот столбец как VARCHAR (MAX), какое-нибудь мошенническое приложение может вставить в него длинную строку, и вы никогда не узнаете об этом или не найдете способ предотвратить это.

В следующий раз, когда ваше приложение будет использовать эту строку,