¿Hay desventajas al usar VARCHAR (MAX) en una tabla?

Question

Aquí está mi situación.

Básicamente, necesito una columna en una tabla para contener una longitud desconocida de caracteres. Pero tenía curiosidad si en SQL Server los problemas de rendimiento pudieran surgir usando un VARCHAR (MAX) o NVARCHAR (MAX) en una columna, como: 'Esta vez' solo necesito almacenar 3 caracteres y la mayoría de las veces solo necesito almacenar 10 caracteres. Pero hay pocas posibilidades de que pueda haber hasta dos mil caracteres en esa columna, o incluso posiblemente un millón. Es impredecible. Pero puedo garantizar que no superará el límite de 2 GB.

Tenía curiosidad por si había algún problema de rendimiento, o posiblemente mejores formas de resolver este problema cuando estuviera disponible.

Answer 1

Me parece que piensa utilizar el tipo de datos varchar (MAX) para su finalidad prevista.

Cuando los datos en un tipo de datos MAX exceden 8 KB, se utiliza una página de sobre flujo. SQL Server 2005 asigna automáticamente un indicador de sobre flujo a la página y sabe cómo manipular las filas de datos de la misma manera que manipula otros tipos de datos.

Para leer más, echa un vistazo a los libros en pantalla: char and varchar

Answer 2

No, varchar (max) se ajusta automáticamente en función del tamaño de la entrada, por lo que es el más eficiente si se va a utilizar entradas de tamaño muy variados.

Answer 3

Acabo de ver el artículo this el otro día. Documenta un retraso de rendimiento bastante menor para varchar (max) sobre una columna varchar (n). Probablemente no lo suficiente como para hacer la diferencia por ti. Pero si lo hace, quizás pueda usar una tabla separada para almacenar esos pocos bloques de texto grandes. Su texto pequeño podría permanecer en la tabla principal, pero podría agregar un campo de bandera para indicarle que busque en la nueva tabla los grandes.

Answer 4

No puede crear índices en varchar(max) (y nvarchar(max)) columnas (aunque pueden ser incluidos en ellos. Pero, ¿quién podría incluir una columna en un índice que podría llegar a 2 GB ?!) por lo que si desea buscar en este valor , realizará un escaneo cada vez, a menos que use índices de texto completo. Además, recuerde que cualquier diseñador de informes o diseñador de presentaciones (web u otro) debe suponer que alguien puede colocar la Enciclopedia en esa columna y diseñar a su alrededor. Nada es peor que escuchar "los usuarios probablemente no hagan X". Si un usuario puede hacerlo, lo hará. Si un usuario puede poner un tomo en una columna, en algún momento lo harán. Si nunca deberían hacerlo, entonces IMO, tiene más sentido limitar el tamaño de la columna a un nivel razonable y si un usuario intenta meter más en esa columna que está permitido, se generaría una discusión sobre si deberían ingresar ese valor en esa columna en primer lugar.

Answer 5

He visto algunos problemas, particularmente con funciones escalares (pero en general son horribles) que devuelven varchar (MAX) y luego no se vuelven a emitir. Por ejemplo, supongamos que tiene una función especial CleanString (somevarcharmax) devuelve varchar (max) y lo llama en varchar (50) pero no CAST (CleanString (varchar10col) AS varchar (10)) - desagradables problemas de rendimiento.

Pero normalmente, cuando tiene columnas varchar (máx) en una tabla, no debería realizar ese tipo de operaciones en masa, por lo que diría que si lo está utilizando correctamente para sus necesidades de datos en la tabla , entonces está bien.

Answer 6

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