¿Por qué no especificar cada VARCHAR como VARCHAR (65535)?

Question

Dado que los requisitos de almacenamiento para un campo Varchar se basan en la longitud real de la cadena ingresada, ¿cuál sería la desventaja de especificar cada campo Varchar como el máximo posible: Varchar (65535)? Bueno, aparte de 1 byte extra para campos máx.> 255 caracteres.

[Reqts de almacenamiento para las cadenas de longitud L: L + 1 bytes si los valores de las columnas requieren 0 - 255 bytes, L + 2 bytes si los valores pueden requerir más de 255 bytes]

Gracias!

Answer 1

Creo que las longitudes de columna varchar no son solo de almacenamiento. También tratan de la semántica de datos.

I.E. especificar una columna name como varchar(100) significa que los nombres almacenados en su sistema no deben tener más de 100 caracteres.

En el lado del almacenamiento de las cosas, deberían ser iguales. Aunque, las estimaciones del tamaño de fila serían más precisas con una longitud específica en varchar columnas que sin ellas (sin necesidad de un sistema de recopilación de estadísticas que mantenga las distribuciones de datos en tamaños varchar).

Answer 2

De los documents - Columna y Fila-Count-límites de tamaño de tabla:

Cada mesa (independientemente del motor de almacenamiento) tiene un tamaño máximo de fila de 65.535 bytes. Los motores de almacenamiento pueden imponer restricciones adicionales a este límite, reduciendo el tamaño de fila máximo efectivo.

El tamaño máximo de fila restringe el número (y posiblemente el tamaño) de las columnas porque la longitud total de todas las columnas no puede exceder este tamaño. Por ejemplo, los caracteres utf8 requieren hasta tres bytes por carácter, por lo que para una columna CHAR (utiles) utf8 CHAR (255), el servidor debe asignar 255 × 3 = 765 bytes por valor. En consecuencia, una tabla no puede contener más de 65,535/765 = 85 de tales columnas.

El almacenamiento para columnas de longitud variable incluye bytes de longitud, que se evalúan con respecto al tamaño de fila. Por ejemplo, una columna uthar8 VARCHAR (255) CHARACTER SET toma dos bytes para almacenar la longitud del valor, por lo que cada valor puede tomar hasta 767 bytes.

Por lo tanto, la definición de una sola columna VARCHAR(65535), efectivamente se limita a una sola columna en la fila (suponiendo que haya llenado para arriba).

Todo esto aparte del hecho de que un tamaño tan grande es completamente incorrecto para algunos tipos de datos; si tiene una columna de número de teléfono que puede contener números locales e internacionales, puede optar por usar un campo VARCHAR para hacerlo , pero fijarlo en algo más de 20 puede no tener sentido (estoy siendo generoso).

Ver this answer de Bill Karwin que también indica posibles penalizaciones de rendimiento si consiguen tablas temporales generados con innecesariamente largo VARCHAR campos (que ver con la conversión de dichos campos a CHAR y viceversa - ver el mensaje para más detalles).

Answer 3

Una posible razón sería mejorar la compatibilidad con otras aplicaciones. Por ejemplo, si tenía una aplicación que utilizaba un campo "product_no" de 100 caracteres de largo y deseaba interactuar con una aplicación que utilizaba un campo similar como "model_no" que tenía 40 caracteres de longitud, sería una molestia.Cualquier product_nos en su aplicación que tuviera más de 40 caracteres se truncaría y tendría que encontrar alguna forma de traducirlos entre las aplicaciones.

Answer 4

Una razón es que el tamaño del campo es un control de los datos ingresados. ¿Realmente quieres que alguien ingrese un número de teléfono de 1000 caracteres? Tener un campo demasiado grande es una forma de garantizar que la basura se ingrese en su base de datos. Tendrá números de teléfono que dicen cosas como (ejemplo no tomadas al azar):

"sólo se habla de la gran rubia en la oficina"

en lugar de un número de teléfono real o AM campo de correo electrónico que contiene notas sobre el cliente porque no tienen un campo de notas? Eso no funciona tan bien cuando intentas enviarle un correo electrónico. Las tablas anchas pueden crear problemas propios en las bases de datos ya que puede encontrarse con límites de registro inesperados (puede diseñar una tabla para ser más ancha de lo que realmente puede almacenarse en un registro, a veces esto hace que las inserciones fallen inesperadamente) y el rendimiento problemas a medida que los datos se separan en las páginas de datos. Sé que puede obtener eso de tablas anchas en SQL Server y no me sorprendería si mysql encuentra problemas similares. Sin embargo, un experto en MySQL tendrá que abordarlo realmente. La indexación también puede ser un problema con campos amplios. El motor de base de datos puede estar menos inclinado a pensar que el índice es útil. De nuevo, no estoy seguro de si mysql tendría este problema, pero es algo para investigar. Sé que estos son problemas con el uso del tamaño de campo máximo para todo en SQL Server, mysql puede tener estos problemas u otros que SQL Server no tiene.

Answer 5

Por ejemplo, el motor de MEMORIA en MySQL no es compatible con VARCHAR-Fields muy bien. El motor reservará para cada fila la cantidad máxima de bytes, no la longitud realmente utilizada. Por lo tanto, si define una tabla con una sola columna VARCHAR (1000), tendrá un uso de memoria de 1000 * 3 bytes por cada fila que agregue, incluso si son cadenas vacías.