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

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

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

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


sql-server varchar nvarchar
person Meiscooldude    schedule 03.04.2010    source источник

Ответы (6)


arrow_upward
15
arrow_downward

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

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

Дополнительную информацию можно найти в электронной документации: char и varchar

person John Sansom    schedule 03.04.2010
comment
Хотя это совершенно верно, я бы избегал использования термина переполнение, поскольку Row-Overflow - это имя типа страницы для varchar (n), в то время как varchar (max) переходит к типу страницы 'Lob Data' при просмотре с использованием DBCC Ind. - person Andrew; 04.04.2010
comment
Итак, ответ на вопрос «есть ли проблемы с производительностью»? Разве это не так - может быть, просто незначительный бит, когда он переполнен? Это правильно? - person Dirk Boer; 21.03.2018

arrow_upward
9
arrow_downward

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

person Thomas    schedule 03.04.2010
comment
Я категорически не согласен. По моему опыту, пользователи нередко на законных основаниях сталкиваются с произвольными ограничениями по размеру. OTOH, я никогда не видел ни одной жалобы на то, что кто-то копирует всю энциклопедию в форму. - person dan04; 08.05.2010
comment
@ dan04 - IME, разработчики часто не тратят время, чтобы получить спецификацию фактического назначения столбца. Проблема с установкой без ограничения заключается в том, что пользователи помещают дерьмо в столбец, потому что они могут, а затем жаловаться, когда их отчеты fubar'ed, или что экран загружается медленно, или что они помещают FirstName LastName в одно поле, и теперь они не могут отсортировать по последнему имя и т. д., поэтому вам нужно прекратить то, что вы делаете, и исправить свои данные. Без какого-либо ограничения нет ничего, что указывало бы, пока не стало слишком поздно, что кто-то пытается засунуть что-то в столбец, которого там не должно быть. - person Thomas; 08.05.2010
comment
Проблема в том, что есть люди, у которых на самом деле 40-буквенные фамилии с несколькими дефисами, и они жалуются, когда вы пытаетесь принудительно преобразовать его в VARCHAR (16). - person dan04; 09.05.2010
comment
@ dan04 - В одном мы согласны: я ненавижу произвольные ограничения размера. Ключевое слово здесь - произвольно. Это означает, что разработчик никогда не консультировался с клиентом или любым другим источником относительно наиболее правильного размера для данного столбца. Таким образом, хотя мы согласны с тем, что varchar (16) для фамилии слишком мало, я бы также сказал, что varchar (max) для фамилии одинаково, если не более идиотично. - person Thomas; 09.05.2010

arrow_upward
3
arrow_downward

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

person Ray    schedule 03.04.2010

arrow_upward
3
arrow_downward

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

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

person Cade Roux    schedule 03.04.2010

arrow_upward
0
arrow_downward

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

person codeulike    schedule 01.09.2010

arrow_upward
-2
arrow_downward

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

person MaQleod    schedule 03.04.2010