MySQL: Por qué especificar el ancho de visualización sin usar zerofill

Question

Recientemente he profundizado en el emocionante mundo de SQL. Todavía estoy tratando de entender bien los conceptos. He estado siguiendo tutoriales en línea. Muchos de estos tutoriales contienen SQL para crear una tabla como esta.

CREATE TABLE `users` (
    `id` tinyint(4) NOT NULL AUTO_INCREMENT, 
    `username` varchar(10) NOT NULL, 
    `password` varchar(100) NOT NULL, 
     PRIMARY KEY (`id`) 
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; 

Después de ver como líneas id tinyint(4) Me preguntaba lo que el parámetro pasado al tipo de datos. Pensé "¿eso quiere decir que la identificación puede ser un número entero entre -128 y 127 (no más de 4 caracteres)?"

Así que consulté los documentos. Esto es lo que MySQL docs have to say about number type attributes.

El ancho de visualización no limita el rango de valores que pueden ser almacenados en la columna. Tampoco impide que los valores más amplios que el ancho de la columna se muestren correctamente. Por ejemplo, una columna especificado como SMALLINT (3) tiene la gama SMALLINT habitual de -32768 a 32.767, y los valores fuera de la gama permitida por tres dígitos se está representada en su totalidad en más de tres dígitos

Cuando se utiliza en junto con el atributo opcional (no estándar) ZEROFILL, el relleno predeterminado de espacios se reemplaza por ceros. Para ejemplo, para una columna declarada como INT (4) ZEROFILL, un valor de 5 se recuperan como 0005.

Así que si estoy leyendo este derecho, declarando cosas como INT(255) son inútiles a menos que utilice zerofill. Ok, tiene sentido que declares un tipo de datos que la base de datos asigna suficiente espacio para esa base de datos.

¿Por qué las personas escriben código como este? ¿Sirve un propósito? ¿Estoy completamente malentendido?

Answer 1

Este ancho de visualización de la "característica adicional" es bastante confuso, porque en otros tipos de columna como CHAR se especifica la longitud.

He aquí una breve desglose:

• Lo más importante: Es no especificando el "espacio de almacenamiento" o "número de dígitos". Solo dice cómo los datos en esta columna son formateados antes de que se devuelvan. INT (5) puede almacenar el mismos valores como INT (16) o INT (255) - los tres pueden almacenar todos (y solo) los valores que son válidos para INT. INT (255) no puede almacenar un número con 255 dígitos. El espacio de almacenamiento para todos ellos es el espacio que ocupa INT.
• Si usa ZEROFILL en una columna con ancho de visualización, y la representación de cadena del número almacenado es más corta que el ancho de visualización, se rellenará con ceros a la izquierda. Si es más largo, no pasa nada. Si elige INT (5) y el valor es 13, se devolverá como 00013. Si el valor es 123456, se devolverá como 123456.
• Si no utiliza ZEROFILL, no habrá ningún relleno (sin espacios y tal)
• Si utiliza ZEROFILL, usted debe ser consciente de que la columna también será UNSIGNED
• En cualquier caso, el ancho de la pantalla se devuelve cuando se consulta la tabla de datos de meta. Entonces, una aplicación podría saber cómo deberían formatearse los datos.

No me agrada el ancho de la pantalla, porque la capa de almacenamiento "conoce" la presentación visual de los datos almacenados. Además de esto, no hay uso que yo sepa.