¿Por qué no usar varchar (max)?

Soy un poco anticuado en lo que respecta al diseño de bases de datos, así que estoy totalmente a favor de usar los tamaños de datos correctos en las columnas. Sin embargo, al revisar la base de datos de un amigo, noté que usaba varchar(max)mucho. Ahora, mi pensamiento inmediato fue devolvérselo y decirle que lo cambiara. Pero luego lo pensé y no pude encontrar una buena razón para que no lo usara (había usado una herramienta de tipo de caso para generar la base de datos, si se lo está preguntando).

He estado investigando el tema del varchar(max)uso y realmente no puedo encontrar una buena razón para que no lo use.

No usa las columnas para los índices, la aplicación que se encuentra en la base de datos tiene limitaciones en la entrada, por lo que no permitirá entradas masivas en los campos.

Se agradecería cualquier ayuda que me ayude a hacerle ver la luz :).

Mi respuesta a esto no se trata del uso de Max, sino del motivo de VARCHAR (max) vs TEXT.

En mi libro; En primer lugar, a menos que pueda estar absolutamente seguro de que nunca codificará nada más que texto en inglés y la gente no hará referencia a nombres de ubicaciones extranjeras, entonces debe usar NVARCHAR o NTEXT.

En segundo lugar, es lo que los campos le permiten hacer.

TEXT es difícil de actualizar en comparación con VARCHAR, pero obtienes la ventaja de la indexación de texto completo y muchas cosas inteligentes.

Por otro lado, VARCHAR (MAX) tiene cierta ambigüedad, si el tamaño de la celda es <8000 caracteres, se tratará como datos de fila. Si es mayor, se tratará como un LOB a efectos de almacenamiento. Debido a que no puede saber esto sin consultar RBAR, esto puede tener estrategias de optimización para lugares donde necesita estar seguro sobre sus datos y cuántas lecturas cuestan.

De lo contrario, si su uso es relativamente mundano y no espera tener problemas con el tamaño de los datos (es decir, está usando .Net y, por lo tanto, no tiene que preocuparse por el tamaño de sus objetos string / char *) entonces usar VARCHAR (max) está bien.

Hay una publicación 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 eran 8K). Entonces, no se puede almacenar un varchar de 2GB (máx.) En la fila de datos. SQL Server lo almacena "Fuera de fila".

Por lo tanto, podría obtener un impacto en el 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 más importante es el rendimiento. Desde problemas generales y de ajuste hasta limitaciones de indexación y cuellos de botella en las consultas. El uso de varcahr (max) o cualquier otro tipo de LOB probablemente contravenga la mayoría de las mejores prácticas de diseño, por lo que, a menos que exista una necesidad comercial específica que no pueda manejarse mediante el uso de algún otro mecanismo de escritura y solo un varchar (max) se ajustará al Bill, entonces, ¿por qué someter su sistema y sus aplicaciones al tipo de problemas generales y de rendimiento inherentes a uno de los tipos de datos LOB?

Si, por otro lado, está trabajando en un entorno OLAP o en un entorno Star Schema DW con tablas de dimensiones con campos de descriptores que naturalmente deben ser detallados, entonces un varchar (max), siempre que no lo agregue a un índice, puede ser útil. Aún así, recomendaría usar un char (x) varchar (x), ya que siempre es una buena práctica usar solo aquellos recursos que absolutamente debes tener para hacer el trabajo.

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

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

Si desea paralizar el rendimiento, use nvarchar para todo.

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

Conclusiones

• Cuando sea apropiado, use VARCHAR (n) sobre VARCHAR (MAX) por razones de buen diseño, si no beneficios de rendimiento, y porque los datos VARCHAR (MAX) no se comprimen
• Almacenar cadenas grandes lleva más tiempo que almacenar cadenas pequeñas.
• Actualizar un valor VARCHAR (MAX) en fila de menos de 8,000 a más de 8,000 será relativamente lento, pero la diferencia para una sola transacción probablemente no sea medible.
• Actualizar 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.
• El uso de la opción fuera de fila para VARCHAR (MAX) provocará escrituras más lentas hasta que las cadenas sean muy largas.

No sé cómo el servidor SQL maneja campos varchar grandes (declarados) desde una perspectiva de rendimiento, memoria y almacenamiento ... pero asumiendo que lo hace tan eficientemente como campos varchar declarados más pequeños, todavía existe el beneficio de las restricciones de integridad.

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

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

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

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

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

   En términos generales, trato de no pasar de varchar (4000), porque después de todo son cuatro mil caracteres . Si excedo eso, busco otros tipos de datos para almacenar lo que sea que esté tratando de almacenar. Brent Ozar ha escrito cosas geniales sobre esto.

   Dicho todo esto, es importante evaluar el enfoque del diseño actual para sus requisitos actuales cuando está trabajando en un proyecto. Tenga una idea de cómo funcionan las distintas partes, comprenda las ventajas y desventajas de los distintos enfoques y resuelva el problema en cuestión. El ejercicio de un gran axioma puede conducir a una adherencia ciega que podría convertirlo en un lemming .