¿Por qué no usar varchar (max)?

Hay una entrada de blog sobre por qué no usar varchar max aquí

Editar

La diferencia básica es dónde se almacenan los datos. Una fila de datos SQL tiene un tamaño máximo de 8000 bytes (o era 8K). Entonces un varchar de 2GB (máximo) no se puede almacenar en la fila de datos. SQL Server lo almacena "Fuera de fila".

Por lo tanto, podría obtener un éxito de rendimiento ya que los datos no estarán en el mismo lugar en el disco, consulte: http://msdn.microsoft.com/en-us/library/ms189087.aspx

Si está trabajando en un entorno OLTP, lo importante es el rendimiento. Desde los gastos generales y las preocupaciones de ajuste hasta las limitaciones de indexación y los cuellos de botella de las consultas. El uso de un varcahr (max) o cualquier otro tipo de LOB probablemente contravendrá la mayoría de las mejores prácticas de diseño, por lo que a menos que haya una necesidad comercial específica que no se pueda manejar a través del uso de algún otro mecanismo de escritura y solo un varchar(max) se ajustará a la factura, entonces ¿por qué someter su sistema y ¿problemas de rendimiento inherentes a uno de los tipos de datos LOB?

Si por el contrario está trabajando en un entorno OLAP o en un entorno DW de Esquema Star con tablas de dimensiones con campos descriptores que naturalmente necesitan ser detallados, entonces un varchar(max), siempre y cuando no esté agregando eso a un índice, puede ser útil. Sin embargo, recomendaría incluso entonces usar un char(x) varchar (x), ya que siempre es una buena práctica usar solo aquellos recursos que absolutamente debe tener para obtener el trabajo Terminado.

NO deben usarse a menos que espere grandes cantidades de datos y aquí está la razón (directamente de Libros en línea):

Columnas que son de los tipos de datos de objeto grande (LOB) ntext, text, varchar (max), nvarchar(max), varbinary (max), xml, o image no pueden ser especificado como columnas clave para un índice.

Si desea paralizar el rendimiento, utilice nvarchar para todo.

No se como sql server maneja los campos varchar grandes (declarados) desde una perspectiva de rendimiento, memoria y almacenamiento.. pero suponiendo que lo hace tan eficientemente como los campos varchar declarados más pequeños, todavía existe el beneficio de las restricciones de integridad.

La aplicación que se encuentra en la base de datos se supone que tiene límites en la entrada, pero la base de datos puede informar correctamente un error si la aplicación tiene un error al respecto.

La diferencia está en siguiente:
VARCHAR(X) se puede indexar y almacenar en el archivo de datos MDF/NDF.
VARCHAR(MAX) no se puede indexar porque puede alcanzar un volumen alto y luego se almacenará como un archivo separado y no en el archivo de datos MDF/NDF.

Es algo anticuado creer que la aplicación solo pasará cadenas cortas a la base de datos, y eso lo hará correcto.

En los tiempos modernos, TIENE para anticipar que la base de datos será accedida principalmente por la aplicación actual, pero puede haber una versión futura de la aplicación, (¿sabrá el desarrollador de esa versión mantener cadenas por debajo de una cierta longitud?)

Usted DEBE anticipar que los servicios web, procesos ETL, LYNC a SQL, y cualquier otro número de tecnologías ya existentes y/o aún no existentes se utilizarán para acceder a su base de datos.

En términos generales trato de no pasar por encima de varchar(4000), porque es cuatro mil caracteres, después de todo. Si supero eso, entonces miro a otros tipos de datos para almacenar lo que sea que estoy tratando de almacenar. Brent Ozar ha escrito bastante gran material sobre esto.

Dicho esto, es importante evaluar la current el enfoque del diseño para sus requisitos current cuando está trabajando en un proyecto. Tenga una idea de cómo funcionan las diversas partes, comprenda las compensaciones de los diversos enfoques y resuelva el problema en cuestión. Ejercer algún gran axioma puede conducir a una adhesión ciega que podría convertirte en un lemming.

Redgate escribió un gran artículo sobre this.
https://www.red-gate.com/simple-talk/sql/database-administration/whats-the-point-of-using-varcharn-anymore/

Conclusiones

• Cuando proceda, utilizar VARCHAR(n) sobre VARCHAR(MAX) por razones de: buen diseño si no beneficios de rendimiento, y porque VARCHAR (MAX) los datos no se comprimen
• Almacenar cadenas grandes lleva más tiempo que almacenar cadenas pequeñas.
• Actualizando una fila VARCHAR (MAX) valor de menos de 8.000 a más de 8.000 será relativamente lento, pero la diferencia para una sola transacción probablemente no será medible.
• Actualizando un valor VARCHAR(MAX) en fila de más de 8,000 a menos de 8,000 será más rápido que si la tabla está configurada para almacenar datos fuera de fila.
• Usar la opción fuera de fila para VARCHAR(MAX) causará escrituras más lentas hasta que las cuerdas sean muy largas.