¿Debo agregar un límite de longitud arbitrario a las columnas VARCHAR?

Según los documentos de PostgreSQL , no hay diferencia de rendimiento entre VARCHAR, VARCHAR(n)y TEXT.

¿Debo agregar un límite de longitud arbitrario a una columna de nombre o dirección ?

Editar: No es un tonto de:

• ¿La búsqueda de índice sería notablemente más rápida con char vs varchar cuando todos los valores son 36 caracteres

Sé que el CHARtipo es una reliquia del pasado y estoy interesado no solo en el rendimiento, sino también en otros pros y contras como Erwin en su sorprendente respuesta.

La respuesta es no .
No agregue un modificador de longitud varcharsi puede evitarlo. La mayoría de las veces, en realidad no necesita una restricción de longitud. Solo utilícelo textpara todos los datos de los personajes. Haga eso varchar(sin modificador de longitud) si necesita mantenerse compatible con RDBMS que no tiene text.

El rendimiento es casi el mismo: textes un poco más rápido en situaciones excepcionales y guarda los ciclos para verificar la longitud.

Si realmente necesita imponer una longitud máxima, aún use texty agregue una restricción de verificación para eso:

ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);

Puede modificar o eliminar dicha restricción en cualquier momento sin tener que meterse con la definición de la tabla y todos los objetos dependientes (vistas, funciones, teclas foráneas, ...)

Con los modificadores de longitud simplemente te encuentras con problemas como este o esto o esto ...

PostgreSQL 9.1 introdujo una nueva característica para aliviar un poco el dolor. Cito las notas de la versión aquí :

Permitir ALTER TABLE ... SET DATA TYPEevitar reescrituras de tablas en casos apropiados (Noah Misch, Robert Haas)

Por ejemplo, convertir una varcharcolumna en texto ya no requiere una reescritura de la tabla. Sin embargo, aumentar la restricción de longitud en una varcharcolumna aún requiere una reescritura de la tabla.

Si ve el límite de longitud como una especie de restricción de verificación para asegurarse de validar los datos, entonces sí agregue uno. En realidad, es posible que no desee utilizar una definición de longitud, sino una restricción de verificación real, para que el cambio del límite sea más rápido.

Para cambiar (aumentar) un límite de longitud, debe ejecutar uno ALTER TABLEque puede tardar mucho tiempo en finalizar (debido a una posible reescritura de la tabla) durante el cual es necesario un bloqueo exclusivo de la tabla.

Cambiar (es decir, eliminar y volver a crear) una restricción de verificación es una operación muy breve y solo requiere leer los datos de la tabla, no cambiará ninguna fila. Por lo tanto, será mucho más rápido (lo que a su vez significa que el bloqueo exclusivo de la tabla se mantendrá durante un período de tiempo mucho más corto).

Durante la operación no hay diferencia alguna entre a text, a varcharo una varchar(5000)columna.

La pregunta es específicamente si se agrega un límite de longitud arbitrario a las columnas VARCHAR?

Para eso, la respuesta es simplemente "no". No hay nada que pueda justificar la adición de un límite arbitrario como lo haría en bases de datos inferiores que admiten varchar(max)o usan convenciones como varchar(255). Sin embargo, si la especificación aborda un límite, creo que la respuesta se vuelve mucho más compleja, especialmente en las versiones modernas de PostgreSQL. Y, por eso, me inclinaría hacia SÍ .

En mi opinión, el límite es una elección acertada si la especificación lo requiere. Especialmente para cargas de trabajo más razonables. Si por ninguna otra razón, para preservar metadatos.

De mi respuesta aquí, indexe el rendimiento de CHAR vs VARCHAR (Postgres) , donde abordo el valor de los metadatos.

Si encontrara una especificación que tuviera claves de texto de longitud variable que fueran significativas y confiara en tener una longitud máxima constante, varchartambién la usaría . Sin embargo, no puedo pensar en nada que se ajuste a ese criterio.

Parece que puede haber alguna diferencia de rendimiento si VARCHARse usa regularmente para almacenar cadenas muy grandes, ya que "las cadenas largas son comprimidas automáticamente por el sistema" y "los valores muy largos también se almacenan en tablas de fondo". Teóricamente, esto significaría que un gran volumen de solicitudes para un campo de cadena muy largo sería más lento que para un campo de cadena corto. Probablemente nunca se encuentre con este problema, ya que los nombres y las direcciones no serán muy largos.

Sin embargo, dependiendo de cómo esté utilizando estas cadenas fuera de su base de datos, es posible que desee agregar un límite práctico para evitar el abuso del sistema. Por ejemplo, si está mostrando el nombre y la dirección en un formulario en algún lugar, es posible que no pueda mostrar un párrafo completo de texto en el campo "nombre", por lo que tendría sentido limitar la columna de nombre a algo así como 500 caracteres.