length - varchar sql server

¿hay una ventaja para varchar(500) sobre varchar(8000)? (5)

He leído sobre esto en los foros de MSDN y aquí y todavía no estoy claro. Creo que esto es correcto: Varchar (max) se almacenará como un tipo de datos de texto, por lo que tiene inconvenientes. Entonces digamos que su campo tendrá menos de 8000 caracteres. Me gusta un campo BusinessName en mi tabla de base de datos. En realidad, un nombre comercial probablemente siempre estará bajo (sacando un número de mi sombrero) 500 caracteres. Parece que muchos de los campos varchar con los que me toco caen bien bajo el conteo de 8k caracteres.

Entonces, ¿debería hacer de ese campo un varchar (500) en lugar de varchar (8000)? Por lo que entiendo de SQL, no hay diferencia entre esos dos. Entonces, para hacer la vida más fácil, me gustaría definir todos mis campos varchar como varchar (8000). ¿Eso tiene algún inconveniente?

Relacionado: Tamaño de columnas varchar (no sentí que este respondiera mi pregunta).

Además de las mejores prácticas (respuesta de BBlake)

Recibe advertencias sobre el tamaño máximo de fila (8060) bytes y el ancho del índice (900 bytes) con DDL
DML morirá si supera estos límites
ANSI PADDING ON es el valor predeterminado, por lo que podría terminar almacenando una carga completa de espacio en blanco

Desde el punto de vista del procesamiento, no hará la diferencia usar varchar (8000) vs varchar (500). Es más un tipo de "buena práctica" definir la longitud máxima que un campo debe contener y hacer que varchar esa longitud. Es algo que se puede usar para ayudar con la validación de datos. Por ejemplo, hacer una abreviatura de estado de 2 caracteres o un código postal / postal de 5 o 9 caracteres. Esta solía ser una distinción más importante para cuando sus datos interactuaban con otros sistemas o interfaces de usuario donde la longitud del campo era crítica (por ejemplo, un conjunto de datos de archivos planos de mainframe), pero hoy en día creo que es más un hábito que cualquier otra cosa.

Hay algunas desventajas para las columnas grandes que son un poco menos obvias y pueden atraparlo un poco más tarde:

Todas las columnas que use en un INDICE - no deben exceder los 900 bytes
Todas las columnas en una cláusula ORDER BY no pueden exceder los 8060 bytes. Esto es un poco difícil de comprender, ya que esto solo se aplica a algunas columnas. Consulte el límite de tamaño de fila de SQL 2008 R2 excedido para obtener más detalles)
Si el tamaño total de la fila supera los 8060 bytes, obtendrá un " derrame de página " para esa fila. Esto podría afectar el rendimiento (una página es una unidad de asignación en SQLServer y se fija a 8000 bytes + algo de sobrecarga. Superar esto no será grave, pero es notorio y debería intentar evitarlo si puede hacerlo fácilmente)
Muchas otras estructuras de datos internas, búferes y, por último, no menos importante, sus propios varaibles y variables de tabla, todos necesitan reflejar estos tamaños. Con tamaños excesivos, la asignación excesiva de memoria puede afectar el rendimiento

Como regla general, trate de ser conservador con el ancho de la columna. Si se convierte en un problema, puede expandirlo fácilmente para satisfacer las necesidades. Si observa problemas de memoria más adelante, puede ser imposible reducir una gran columna más adelante sin perder datos y no sabrá por dónde empezar.

En su ejemplo de nombres comerciales, piense dónde puede mostrarlos. ¿Hay realmente espacio para 500 personajes? Si no, no tiene mucho sentido almacenarlos como tales. http://en.wikipedia.org/wiki/List_of_companies_of_the_United_States enumera algunos nombres de compañías y el máximo es de aproximadamente 50 caracteres. Entonces usaría 100 para la columna max. Tal vez más como 80.

Lo ideal sería que fuera más pequeño que eso, hasta una longitud razonablemente grande (500 no es de un tamaño razonable) y asegúrese de que la validación del cliente capte cuando los datos sean demasiado grandes y envíe un error útil.

Si bien el varchar no va a reservar espacio en la base de datos para el espacio no utilizado, recuerdo que las versiones de SQL Server tienen un zumbido sobre las filas de la base de datos que son más grandes que algunos bytes (no recuerdo el recuento exacto) y cualquiera que sea la información no encaja. Una cierta cantidad de esos bytes se reservaron para cosas internas de SQL Server.

Un ejemplo en el que esto puede marcar la diferencia es que puede evitar una optimización del rendimiento que evite agregar información de versiones de filas a tablas con desencadenadores posteriores.

Esto está cubierto por SQL Kiwi aquí

El tamaño real de los datos almacenados es inmaterial; lo que importa es el tamaño potencial.

Del mismo modo, si se utilizan tablas optimizadas para la memoria desde 2016, ha sido posible utilizar columnas LOB o combinaciones de anchuras de columna que podrían exceder potencialmente el límite inicial pero con una penalización.

Las columnas (máx.) Siempre se almacenan fuera de la fila. Para otras columnas, si el tamaño de la fila de datos en la definición de la tabla puede exceder los 8.060 bytes, SQL Server empuja la (s) columna (s) de longitud variable más grande fuera de la fila. Nuevamente, no depende de la cantidad de datos que almacene allí.

Esto puede tener un gran efecto negativo en el consumo de memoria y el rendimiento

Otro caso donde el exceso de anchos de columna puede marcar una gran diferencia es si la tabla alguna vez será procesada usando SSIS. La memoria asignada para las columnas de longitud variable (no BLOB) se fija para cada fila en un árbol de ejecución y es por la longitud máxima declarada de las columnas, lo que puede conducir a un uso ineficaz de los búferes de memoria (example) . Mientras que el desarrollador del paquete SSIS puede declarar un tamaño de columna más pequeño que la fuente, este análisis se realiza mejor por adelantado y se aplica allí.

De vuelta en el propio motor de SQL Server, un caso similar es que, al calcular la concesión de memoria para asignar para operaciones SORT , SQL Server asume que las columnas varchar(x) en promedio consumirán x/2 bytes.

Si la mayoría de sus columnas varchar son más completas que eso, esto puede llevar a que las operaciones de sort derramen a tempdb .

En su caso, si sus columnas varchar están declaradas como 8000 bytes, pero en realidad tienen contenidos mucho menores a los de su consulta, se asignará una memoria que no requiere, lo que obviamente es ineficiente y puede llevar a la espera de concesiones de memoria.

Esto se trata en la Parte 2 de SQL Workshops Webcast 1 descargable desde aquí o vea a continuación.

use tempdb; CREATE TABLE T( id INT IDENTITY(1,1) PRIMARY KEY, number int, name8000 VARCHAR(8000), name500 VARCHAR(500)) INSERT INTO T (number,name8000,name500) SELECT number, name, name /*<--Same contents in both cols*/ FROM master..spt_values SELECT id,name500 FROM T ORDER BY number

SELECT id,name8000 FROM T ORDER BY number