Почему бы не использовать varchar (max)?

Question

Я немного староват, когда дело доходит до проектирования баз данных, поэтому я полностью использую правильные размеры данных в столбцах.Однако, просматривая базу данных для друга, я заметил, что он много использовал varchar(max).Теперь, моей непосредственной мыслью было вернуть его ему и сказать, чтобы он изменил это.Но потом я подумал об этом и не смог придумать для него вескую причину не использовать его (если вам интересно, он использовал инструмент типа дел для создания БД).

IЯ исследовал тему использования varchar(max), и я не могу придумать для него веской причины не использовать его.

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

Буду признателен за любую помощь, чтобы помочь мне заставить его увидеть свет :)

Answer 1

Мой ответ на этот вопрос не об использовании Max, а о причине, по которой VARCHAR (max) сравнивается с TEXT.

В моей книге; Прежде всего, если вы не можете быть абсолютно уверены в том, что никогда не будете кодировать ничего, кроме английского текста и люди не будут ссылаться на названия иностранных локаций, тогда вам следует использовать NVARCHAR или NTEXT.

Во-вторых, это то, что поля позволяют вам делать.

ТЕКСТ сложно обновить по сравнению с VARCHAR, но вы получаете преимущество полнотекстовой индексации и множества умных вещей.

С другой стороны, VARCHAR (MAX) имеет некоторую двусмысленность, если размер ячейки

В противном случае, если вы пользуетесь относительно обыденно, и вы не ожидаете проблем с размером данных (т. Е. Вы используете .Net, и поэтому вам не нужно беспокоиться о размере строки / символа). * объекты), тогда использование VARCHAR (макс.) нормально.

Answer 2

В блоге есть сообщение о том, почему бы не использовать varchar max здесь

Редактировать

Основная разница в том, где хранятся данные. Максимальный размер строки данных SQL составляет 8000 байт (или 8K). Тогда 2 ГБ varchar (max) не может быть сохранен в строке данных. SQL Server хранит его «Out of row».

Таким образом, вы можете получить снижение производительности, поскольку данные не будут находиться в одном и том же месте на диске, см .: http://msdn.microsoft.com/en-us/library/ms189087.aspx

Answer 3

Если вы работаете в среде OLTP, вы все о производительности.От накладных расходов и проблем настройки до ограничений индексации и узких мест запросов.Использование varcahr (max) или любого другого типа LOB, скорее всего, будет противоречить большинству передовых методов проектирования, поэтому, если нет особой бизнес-потребности, которая не может быть решена с помощью какого-либо другого механизма ввода, и только varchar (max) будет соответствоватьВ таком случае, зачем подвергать вашу систему и приложения таким проблемам, связанным с накладными расходами и производительностью, которые присущи одному из типов данных больших объектов?

Если, с другой стороны, вы работаете в среде OLAP или в среде DW Star Schema сТаблицы измерений с полями дескрипторов, которые, естественно, должны быть подробными, а затем varchar (max), если вы не добавляете это в индекс, могут быть полезны.Тем не менее, я бы порекомендовал даже тогда использовать char (x) varchar (x), так как всегда рекомендуется использовать только те ресурсы, которые вам абсолютно необходимы для выполнения работы.

Answer 4

Redgate написал отличную статью по этому поводу.
https://www.red -gate.com / simple-talk / sql / database-Administration / Whats-the-Point-of-Use-varcharn-anymore /

Выводы

• При необходимости используйте VARCHAR (n) вместо VARCHAR (MAX) по соображениям хорошего дизайна, если не для повышения производительности, а также потому, что VARCHAR(MAX) данные не сжимаются
• Хранение больших строк занимает больше времени, чем сохранение маленьких строк.
• Обновление значения VARCHAR (MAX) в строке ниже 8000 до более 8000 будет относительно медленным,но разница для одной транзакции, скорее всего, не будет измеримой.
• Обновление значения VARCHAR (MAX) в строке с более 8 000 до 8 000 будет быстрее, чем если бы таблица была настроена для хранения данных вне-row.
• Использование параметра вне строки для VARCHAR (MAX) приведет к более медленной записи, пока строки не станут очень длинными.

Answer 5

Они НЕ должны использоваться, если вы не ожидаете больших объемов данных, и вот причина (прямо из Books Online):

Столбцы, имеющие типы данных больших объектов (LOB) ntextтекст, varchar (max), nvarchar (max), varbinary (max), xml или изображение не могут быть указаны в качестве ключевых столбцов для индекса.

Если вы хотите снизить производительность, используйте nvarcharза все.

Answer 6

Несколько старомодно полагать, что приложение будет передавать только короткие строки в базу данных, и это будет нормально .

В наше время вы ЕСТЬ ожидаете, что к базе данных будет обращаться, главным образом, из текущего приложения, но может существовать будущая версия приложения (будет ли разработчик этой версии знать, чтобы сохранить строки ниже определенной длины?)

Вы ДОЛЖНЫ ожидать, что для доступа к вашей базе данных будут использоваться веб-сервисы, процессы ETL, LYNC to SQL и любое другое количество уже существующих и / или еще не существующих технологий.

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

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

Answer 7

Разница в следующем:
VARCHAR(X) можно проиндексировать и сохранить в файле данных MDF/NDF.
VARCHAR(MAX) не может быть проиндексирован, поскольку может достигать большого объема и затем будет сохраняться как отдельный файл, а не в файле данных MDF/NDF.

Answer 8

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

Приложение, находящееся в БД, имеет предполагается, что имеет ограничения на ввод, но база данных может правильно сообщить об ошибке, если приложение имеет ошибку в этом отношении.