Есть ли какие-то скрытые ловушки, меняющие колонку с varchar (8000) на varchar (max)?

Question

У меня есть много (более тысячи мест) устаревшего кода T-SQL, который превращает INSERT s в столбец varchar(8000) в служебной таблице. Наши потребности изменились, и теперь этот столбец должен обрабатывать большие значения. В результате мне нужно сделать этот столбец varchar(max). Это просто простой столбец данных, в котором нет предварительно выполненных поисков, нет индекса по нему, только одна процедура читает его, это INSERT и забыто для приложения (почти как запись в журнале).

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

• Есть ли какие-либо скрытые ловушки, изменяющие столбец с varchar(8000) на varchar(max)?
• Будут ли все строковые функции T-SQL работать одинаково, LEN(), RTRIM(), SUBSTRING() и т. Д.
• Может кто-нибудь представить себе причину, по которой мне пришлось бы вносить какие-либо изменения в код, который считает, что столбец все еще varchar(8000)?

Answer 1

• Все типы MAX имеют небольшое снижение производительности, см. Сравнение производительности varchar (max) с varchar (N) .
• Если ваше обслуживание включает онлайн-операции (перестроение онлайн-индекса), вы потеряете возможность их выполнять. Операции онлайн не поддерживаются для таблиц с BLOB-столбцами :

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

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

Answer 2

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 3

Если вам действительно не нужны индексы, и это большой столбец, то все будет в порядке.Varchar (max) кажется именно тем, что вам нужно, и у вас будет меньше проблем с существующим кодом, чем если бы вы использовали текст.

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