Cualquier trampa oculta que cambie una columna de varchar (8000) a varchar (max)?

Question

Tengo un montón (más de mil lugares) de código T-SQL heredado que solo hace INSERT s en una columna varchar(8000) en una tabla de servicios. Nuestras necesidades han cambiado y ahora esa columna necesita poder manejar valores más grandes. Como resultado, necesito hacer esa columna varchar(max). Esta es solo una columna de datos sin formato donde no hay búsquedas realizadas, ningún índice, solo un procedimiento lo lee, es INSERT y se olvida de la aplicación (casi como una entrada de registro).

Planeo hacer cambios en solo unos pocos lugares que realmente generarán los datos más grandes, y en el único procedimiento almacenado que procesa esta columna.

• ¿Hay trampas ocultas cambiantes una columna de varchar(8000) a un varchar(max)?
• hará que todas las funciones de cadena T-SQL la misma, LEN(), RTRIM(), SUBSTRING(), etc.
• Puede alguien imaginar ninguna razón por la que tendría que realizar ningún cambio en el código que piensa que la columna es todavía varchar(8000)?

Answer 1

• Todos los tipos MAX tienen una pequeña penalización de rendimiento, consulte Performance comparison of varchar(max) vs. varchar(N).
• Si su mantenimiento incluye operaciones en línea (reconstrucción del índice en línea), perderá la posibilidad de hacerlas. Online operations are not supported for tables with BLOB columns:

  • se deben crear índices agrupados, reconstruido, o se ha caído desconectado cuando la tabla subyacente contiene objetos grandes (LOB) tipos de datos: imagen, ntext, texto, varchar (max), nvarchar (max) , varbinary (max) y xml.
  • Los índices no agrupados nonunique se pueden crear en línea cuando la tabla contiene tipos de datos LOB, pero ninguna de estas columnas se utiliza en la definición del índice como columnas clave o no clave (incluidas). Los índices no agrupados definidos con columnas de tipo de datos LOB deben crearse o reconstruirse fuera de línea.

La penalización de rendimiento es muy pequeña, así que no se preocupe. La pérdida de la capacidad de realizar reconstrucciones en línea puede ser problemática para las tablas de operaciones realmente imprescindibles en línea. A menos que las operaciones en línea sean imprescindibles, votaría por hacerlo y lo cambiaría a MAX.

Answer 2

Si realmente no necesita índices y es una columna grande, debería estar bien. Varchar (max) parece ser exactamente lo que necesita y tendrá menos problemas con el código existente que si usara texto.

Asegúrese de probar las actualizaciones donde se agrega texto al texto existente. Debería funcionar con una concatenación regular, pero me gustaría poder probarlo.

Answer 3

Crystal Reports 12 (y otras versiones, hasta donde yo sé) no maneja adecuadamente varchar (max) y lo interpreta como varchar (255) que conduce a datos truncados en los informes.

Si está utilizando Crystal Reports, eso es una desventaja para varchar (max). O una desventaja al uso de Crystal, para ser precisos.

Ver:
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