example - mysql varchar length
MySQL: ¿Por qué usar VARCHAR(20) en lugar de VARCHAR(255)? (6)
Bueno, si desea permitir una entrada más grande, o limitar el tamaño de la entrada, tal vez.
Por ejemplo, puede tener first_name como VARCHAR 20, pero quizás street_address como VARCHAR 50 ya que 20 puede no ser suficiente. Al mismo tiempo, es posible que desee controlar qué tan grande puede obtener ese valor.
En otras palabras, ha establecido un techo de cuán grande puede ser un valor particular, en teoría para evitar que la tabla (y potencialmente las entradas de índice / índice) se vuelva demasiado grande.
También puede usar CHAR que tiene un ancho fijo, pero a diferencia de VARCHAR, que puede ser más pequeño, CHAR rellena los valores (aunque esto hace que el acceso a SQL sea más rápido).
Posible duplicado:
¿Hay desventajas al usar un varchar genérico (255) para todos los campos basados en texto?
En MYSQL puede elegir una longitud para el tipo de campo VARCHAR. Los valores posibles son 1-255.
Pero, ¿cuáles son sus ventajas si usa VARCHAR (255) que es el máximo en lugar de VARCHAR (20)? Hasta donde yo sé, el tamaño de las entradas depende solo de la longitud real de la cadena insertada.
tamaño (bytes) = longitud + 1
Entonces, si tiene la palabra "Ejemplo" en un campo VARCHAR (255), tendría 8 bytes. Si lo tiene en un campo VARCHAR (20), también tendrá 8 bytes. ¿Cuál es la diferencia?
Espero que puedas ayudarme. ¡Gracias por adelantado!
Desde una perspectiva de la base de datos en cuanto al rendimiento, no creo que vaya a haber una diferencia.
Sin embargo, creo que gran parte de la decisión sobre el tiempo de uso se reduce a lo que está tratando de lograr y documentando el sistema para aceptar solo los datos que necesita.
Existen muchas razones válidas para elegir un valor menor que el máximo que no esté relacionado con el rendimiento. Establecer un tamaño ayuda a indicar el tipo de datos que está almacenando y también puede actuar como una forma de validación de última hora.
Por ejemplo, si está almacenando un código postal del Reino Unido, solo necesita 8 caracteres. Establecer este límite ayuda a aclarar el tipo de datos que está almacenando. Si eliges 255 caracteres, simplemente confundiría las cosas.
Hay una diferencia semántica (y creo que esa es la única diferencia): si intentas llenar 30 caracteres no espaciales en varchar (20), se producirá un error, mientras que tendrá éxito para varchar (255). Por lo tanto, es principalmente una restricción adicional.
Salida: Referencia para Varchar
En resumen, no hay mucha diferencia a menos que supere el tamaño de 255 en su VARCHAR, lo que requerirá otro byte para el prefijo de longitud.
La longitud indica más de una restricción en los datos almacenados en la columna que cualquier otra cosa. Esto también restringe intrínsecamente el tamaño MÁXIMO de almacenamiento para la columna. En mi humilde opinión, la longitud debe tener sentido con respecto a los datos. Si almacena un número de Seguridad Social, no tiene sentido establecer la longitud en 128, aunque no le cueste nada en almacenamiento si todo lo que almacena es un SSN.
No sé acerca de mySQL, pero en SQL Server le permitirá definir campos de modo que la cantidad total de bytes utilizados sea mayor que la cantidad total de bytes que realmente se pueden almacenar en un registro. Esto es algo malo. Tarde o temprano obtendrá una fila donde se alcanza el límite y no puede insertar los datos.
Es mucho mejor diseñar la estructura de su base de datos para considerar los límites de tamaño de fila.
Además, sí, no desea que las personas pongan 200 caracteres en un campo donde el valor máximo debería ser 10. Si lo hacen, casi siempre son datos incorrectos.
Usted dice, bueno, puedo limitar eso a nivel de aplicación. Pero los datos no ingresan a la base de datos solo desde una aplicación. A veces las aplicaciones múltiples lo utilizan, a veces los datos se importan y, a veces se arregla manualmente desde la ventana de consulta (actualizar todos los registros para agregar un 10% al precio, por ejemplo). Si alguna de estas otras fuentes de datos no conoce las reglas que pone en su aplicación, tendrá datos inútiles en su base de datos. La integridad de los datos debe aplicarse en el nivel de la base de datos (lo que no impide que usted también verifique antes de intentar ingresar datos) o no tiene integridad. Además, según mi experiencia, las personas que son demasiado perezosas para diseñar su base de datos a menudo también son demasiado perezosas para poner realmente los límites en la aplicación y no hay ningún control de integridad de datos.
Tienen una palabra para las bases de datos sin integridad de datos, inútil.