Любые скрытые ловушки, изменяющие столбцы от varchar (8000) до varchar (max)?

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

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

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

Ответы

Ответ 1

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

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

Ответ 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

Ответ 3

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

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