Есть ли недостатки в использовании VARCHAR (MAX) в таблице?

Question

Вот мое затруднение.

По сути, мне нужен столбец в таблице для хранения неизвестной длины символов. Но мне было любопытно, если бы в Sql Server проблемы с производительностью могли возникать при использовании VARCHAR (MAX) или NVARCHAR (MAX) в столбце, например: «На этот раз», мне нужно хранить только 3 символа и большую часть времени мне нужно хранить 10 символов. Но есть небольшие шансы, что в этом столбце может быть до пары тысяч символов или даже миллион. Это непредсказуемо. Но я могу гарантировать, что он не превысит лимит в 2 ГБ.

Мне было просто любопытно, есть ли проблемы с производительностью или, возможно, более эффективные способы решения этой проблемы, если таковые имеются.

Answer 1

Похоже, вы планируете использовать тип данных varchar (MAX) по прямому назначению.

Когда данные в типе данных MAX превышают 8 КБ, используется страница переполнения. SQL Server 2005 автоматически назначает странице индикатор переполнения и знает, как управлять строками данных так же, как он манипулирует другими типами данных.

Для дальнейшего чтения, ознакомьтесь с Books Online: char and varchar

Answer 2

Вы не можете создавать индексы для varchar(max) (и nvarchar(max)) столбцов (хотя они могут быть включены в них. Но кто будет включать столбец в индекс, который может получить до 2 ГБ ?!), поэтому, если вы хотите искать по этому значению вы будете выполнять сканирование каждый раз, если не используете полнотекстовые индексы. Кроме того, помните, что любой дизайнер отчетов или дизайнер презентаций (веб или иным образом) должен предполагать, что кто-то может поместить энциклопедию в эту колонку и создать вокруг нее дизайн. Нет ничего хуже, чем услышать, что «пользователи, вероятно, не будут делать X». Если пользователь может сделать это, он сделает это. Если пользователь может поместить том в столбец, в какой-то момент он это сделает. Если они никогда не должны этого делать, тогда, по IMO, имеет смысл ограничить размер столбца на каком-то разумном уровне, и если пользователь пытается добавить больше в этот столбец, который разрешен, это вызовет дискуссию о том, должны ли они вводить это значение этот столбец в первую очередь.

Answer 3

Я видел некоторые проблемы - особенно со скалярными функциями (но они вообще ужасны, так или иначе), которые возвращают varchar (MAX), а затем не пересматриваются. Например, допустим, у вас есть специальная функция CleanString (somevarcharmax), возвращает varchar (max) и вызывает ее для varchar (50), но не выполняет CAST (CleanString (varchar10col) AS varchar (10)) - неприятные проблемы с производительностью.

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

Answer 4

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

Answer 5

Crystal Reports 12 (и, насколько мне известно, другие версии) неправильно обрабатывает varchar (max) и интерпретирует его как varchar (255), что приводит к усеченным данным в отчетах.

Так что есливы используете Crystal Reports, это недостаток для varchar (max).Или недостаток в использовании Crystal, если быть точным.

См .:
http://www.crystalreportsbook.com/Forum/forum_posts.asp?TID=5843&PID=17503
http://michaeltbeeitprof.blogspot.com/2010/05/crystal-xi-and-varcharmax-aka-memo.html

Answer 6

Нет, varchar (max) настраивается в зависимости от размера записи, поэтому он наиболее эффективен, если вы будете использовать входы различного размера.