MySQL: ¿Por qué usar VARCHAR (20) en lugar de VARCHAR (255)?

Duplicar posible:
Are there disadvantages to using a generic varchar(255) for all text-based fields?MySQL: ¿Por qué usar VARCHAR (20) en lugar de VARCHAR (255)?

en MySQL se 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

lo tanto, si usted tiene la palabra "Ejemplo" en un campo VARCHAR (255), que tendría 8 bytes. Si lo tiene en un campo VARCHAR (20), también tendrá 8 bytes. ¿Cuál es la diferencia?

Espero que me puedan ayudar. ¡Gracias por adelantado!

Fuente

2009-08-11 caw

Salida: Reference for Varchar

En resumen no hay mucha diferencia a menos que excede el tamaño de 255 en su VARCHAR 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 en 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.

Fuente

2009-08-11 18:38:06

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.

Se podía utilizar CHAR que es un ancho fijo también, pero a diferencia de VARCHAR, que puede ser más pequeño, CHAR almohadillas de los valores (aunque esto lo convierte en el acceso SQL más rápido.

Fuente

2009-08-11 18:39:02 OneNerd

¿Pero por qué debería establecer la longitud a 20 en absoluto? Si no hay diferencia, simplemente puedo configurarlo en 255 para todos los campos, ¿o no? – caw

ver mi edición - elaboro un poco más. – OneNerd

Gracias. Por lo tanto, no hace ninguna diferencia al almacenamiento y rendimiento convergentes, ¿verdad? Pero puede ser útil, sin embargo, p. si quieres cortar cuerdas para evitar las largas. Pero también podría lograr esto antes si utilizara substr() en PHP o una función similar en otro idioma. – caw

De una actuación perspectiva de base de datos inteligente que hago 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.

Fuente

2009-08-11 18:39:08

"Tenga en cuenta que el uso de CHAR solo acelerará su acceso si el registro completo es de tamaño fijo. Es decir, si utiliza cualquier objeto de tamaño variable, también puede hacer que todos ellos sean de tamaño variable. No gana velocidad usando un CHAR en una tabla que también contiene un VARCHAR ". [enlace] (http://dev.mysql.com/doc/refman/5.0/en/char.html) –

Hay muchas razones válidas para elegir un valor más pequeño que el máximo que ar e no 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, entonces 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.

Fuente

2009-08-11 18:50:12

+1 para enfatizar la claridad y la inteligibilidad. Ciertamente cuestionaría el uso de un buf [1024], un 'nuevo DynamicBuf (1024)' o un VARCHAR (255) para almacenar, por ejemplo, una única dirección IP de cuatro puntos. ¿El codificador sabía lo que estaba haciendo? – pilcrow

+1 Y si elige VARCHAR (8) para los códigos postales del Reino Unido, use CHAR (8) para el rendimiento :) –

Si desea almacenar el código postal de 8 caracteres, debe usar CHAR (8) en su lugar. Es mejor evitar la presencia de la columna VARCHAR en la tabla, ya que fuerza la longitud de la fila varibale y la búsqueda más lenta en la tabla. Sin embargo, si no puede tener todas las columnas de longitud fija, no importa. –

Hay una diferencia semántica (y creo que esa es la única diferencia): si intenta llenar 30 caracteres no espaciales en varchar (20), producirá un error, mientras que tendrá éxito para varchar (255) . Por lo tanto, es principalmente una restricción adicional.

Fuente

2009-08-11 18:50:48

Pero no está claro que 30 caracteres no cabe en un campo de 20 bytes – caw

Como dices, la representación de almacenamiento realmente no se preocupa por la longitud: un campo declarado varchar (20) podría almacenar 30 caracteres, en lo que respecta a la representación del disco - pensé que esta observación era el núcleo de tu pregunta (por qué no siempre utilizas varchar (255)?) Ahora, te estoy diciendo la razón por la que estableces varchar (20): porque * quieres * el error que obtienes si accidentalmente intentas ingresar más de 20 caracteres. –

Entonces, solo es para problemas de validación, ¿correcto? – caw

No sé sobre mySQL, pero en SQL Server le permitirá definir campos tales que el número total de bytes utilizados es mayor que el número 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 en el nivel de la 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 también se 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.

Fuente

2009-08-12 20:10:54 HLGEM

MySQL: ¿Por qué usar VARCHAR (20) en lugar de VARCHAR (255)?

Respuesta

Cuestiones relacionadas