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

Question

Вот мое затруднительное положение.

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

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

Answer 1

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

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

Для дальнейшего чтения, проверить Books Online: char and varchar

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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