Есть ли недостатки в использовании VARCHAR (MAX) в таблице?
Вот еще один способ (этот работает внутри для циклов):
var someVar = some_other_function();
someObj.addEventListener("click",
function(theVar){
return function(){some_function(theVar)};
}(someVar),
false);
5 ответов
Мне кажется, вы планируете использовать тип данных varchar (MAX) по прямому назначению.
Когда данные в типе данных MAX превышают 8 КБ, используется страница переполнения. SQL Server 2005 автоматически назначает странице индикатор переполнения и знает, как манипулировать строками данных так же, как и другими типами данных.
Дополнительную информацию можно найти в электронной документации: char and varchar
Нет, varchar (max) настраивается в зависимости от размера записи, поэтому наиболее эффективно, если вы будете использовать входные данные самого разного размера.
Вы не можете создавать индексы для varchar (max) (и ] nvarchar (max) ) столбцы (хотя они могут быть включены в них. Но кто будет включать столбец в индекс, который может достигать 2 ГБ ?!), поэтому, если вы хотите выполнить поиск по этому значению, вы выполните сканировать каждый раз, если вы не используете полнотекстовые индексы. Кроме того, помните, что любой дизайнер отчетов или дизайнер презентаций (веб-сайтов или других) должен исходить из того, что кто-то может поместить Энциклопедию в эту колонку и создать дизайн вокруг нее. Нет ничего хуже, чем услышать «пользователи, вероятно, не будут делать X». Если пользователь может это сделать, они это сделают. Если пользователь может поместить фолиант в столбец, в какой-то момент они это сделают. Если они никогда не должны этого делать, то, IMO, имеет смысл ограничить размер столбца на некотором разумном уровне, и если пользователь попытается добавить в этот столбец больше, что разрешено, это вызовет обсуждение того, должны ли они вводить это значение в этот столбец в первую очередь.
Я только что видел эту статью на днях. Он документирует довольно незначительное отставание в производительности для varchar (max) от столбца varchar (n). Вероятно, этого недостаточно, чтобы что-то изменить. Но если это так, возможно, вы можете использовать отдельную таблицу для хранения этих нескольких больших текстовых блоков. Ваш небольшой текст может оставаться в основной таблице, но вы можете добавить поле флага, чтобы указать вам искать в новой таблице большие.
Я видел некоторые проблемы - особенно со скалярными функциями (но они, как правило, ужасны), которые возвращают varchar (MAX), а затем не повторно -В ролях. Например, скажем, у вас есть специальная функция CleanString (somevarcharmax), которая возвращает varchar (max) и вызывает ее на varchar (50), но не CAST (CleanString (varchar10col) AS varchar (10)) - неприятные проблемы с производительностью.
Но обычно, когда у вас есть столбцы varchar (max) в таблице, вам не следует выполнять такие операции в массовом порядке, поэтому я бы сказал, если вы правильно используете его для своих данных в таблице, тогда все нормально.