Duda declarar tipo de columna en tabla (tamaño)

[neodani]

Buenas,

Tengo una duda (tonta) que quiero asegurarme qué significa realmente esto

id int(2) NOT NULL auto_increment,

Mi duda no está en el auto_increment, sino es más básica aún. Que significa int(2)

Es la longitud de la columna en bytes?

Yo creo que es el tamaño en bytes, pero cuantos números se pueden crear en 2 bytes? :S

¿Es correcto el calculo 2 bytes = a 8bits por tanto 2^8 numeros? 256 numeros caben en un int(2) y por tanto en un int(3) se calcuaria siempre de la misma forma 3byes = 12bits >> 2^12 son los nuemros para int(3) ?¿?¿?

Muchas gracias de antemano!

[huesos52]

MySQL soporta otra extensión para especificar de forma óptima el ancho a mostrar de un tipo entero en paréntesis después de la palabra clave para el tipo (por ejemplo, INT(4)). Esta especificación opcional del ancho de muestra se usa para alinear a la izquierda la muestra de los valores con ancho menor que el ancho especificado para la columna.

El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.

Cuando se usa en conjunción con el atributo de extensión opcional ZEROFILL, el relleno por defecto de espacios se replaza por ceros. Por ejmplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004. Tenga en cuenta que si almacena valores mayores que el ancho de muestra en una columna entera, puede tener problemas cuando MySQL genera tablas temporales para algunos joins complicados, ya que en estos casos MySQL cree que los datos encajan en el ancho original de la columna.

tomado de http://dev.mysql.com/doc/refman/5.0/...ric-types.html

Código mysql:

mysql> create table ad(id int(9));
Query OK, 0 rows affected (0.01 sec)
 
mysql> insert into ad values(4);
Query OK, 1 row affected (0.00 sec)
 
mysql> select *from ad;
+------+
| id   |
+------+
|    4 |
+------+
1 row in set (0.00 sec)
 
mysql> drop table ad;
Query OK, 0 rows affected (0.01 sec)
 
mysql> create table ad(id int(9) zerofill);
Query OK, 0 rows affected (0.01 sec)
 
mysql> insert into ad values(4);
Query OK, 1 row affected (0.00 sec)
 
mysql> select *from ad;
+-----------+
| id        |
+-----------+
| 000000004 |
+-----------+
1 row in set (0.00 sec)
 
mysql>
 

[gnzsoloyo]

Eso se responde leyendo el Manual de Referencia: 11.2. Tipos numéricos.
El tipo de columna define el rango de representación. Ese otro valor tiene otro uso, y cito:

MySQL soporta otra extensión para especificar de forma óptima el ancho a mostrar de un tipo entero en paréntesis después de la palabra clave para el tipo (por ejemplo, INT(4)). Esta especificación opcional del ancho de muestra se usa para alinear a la izquierda la muestra de los valores con ancho menor que el ancho especificado para la columna.

El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, no el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.

Cuando se usa en conjunción con el atributo de extensión opcional ZEROFILL, el relleno por defecto de espacios se replaza por ceros. Por ejmplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004. Tenga en cuenta que si almacena valores mayores que el ancho de muestra en una columna entera, puede tener problemas cuando MySQL genera tablas temporales para algunos joins complicados, ya que en estos casos MySQL cree que los datos encajan en el ancho original de la columna.

Ejemplificando, si combinas en la declaración un INT(5) con ZEROFILL, y tienes ingresado un 23 en la tabla, al realizar el SELECT el resultado será 00023, en lugar de 23.
Fuera de eso, no tiene utilidad, pero el MySQL te lo pone por default al límite de representación.

[neodani]

Iniciado por gnzsoloyo

Eso se responde leyendo el Manual de Referencia: 11.2. Tipos numéricos.
El tipo de columna define el rango de representación. Ese otro valor tiene otro uso, y cito:

Ejemplificando, si combinas en la declaración un INT(5) con ZEROFILL, y tienes ingresado un 23 en la tabla, al realizar el SELECT el resultado será 00023, en lugar de 23.
Fuera de eso, no tiene utilidad, pero el MySQL te lo pone por default al límite de representación.

Es decir, que según la tabla si yo declaro un

campo INT a secas puedo guardar 2147483647 números?

Y sí sé que no se va a llegar a 30000 registros puedo declarar

campo SMALLINT porque soporta hasta 32767 números y así ahorrar espacio en la bbdd?

Si es correcto esto... ya sé kung-fu :D

Muchas gracias de antemano

[gnzsoloyo]

Y sí sé que no se va a llegar a 30000 registros puedo declarar

campo SMALLINT porque soporta hasta 32767 números y así ahorrar espacio en la bbdd

Exactamente ese es el criterio para seleccionar los tipos de datos de las columnas: No menos de lo que se necesita, pero tampoco más de los necesarios.

[neodani]

Iniciado por gnzsoloyo

Exactamente ese es el criterio para seleccionar los tipos de datos de las columnas: No menos de lo que se necesita, pero tampoco más de los necesarios.

Genial, muchas gracias ;)

[neodani]

Por cierto,

¿Hay algún inconveniente en declarar una columna como SMALLINT (para 32767) y luego a medida que pase el tiempo ver que se queda pequeña, se puede cambiar el tipo al siguiente MEDIUMINT (para 8388607) ?

Se perjudica/corrompe en algo la bbdd? es posible? sería haciendo un update?

Muchas gracias

[gnzsoloyo]

No perjudica ni corrompe. Lo único que sucede es que se debe evitar modificar la estructura de una base de datos cuando la base ya está en funcionamiento, por los múltiples problemas que eso produce.
Entiéndase por problemas desde incompatibilidad de los backups realizados con anterioridad, hasta la necesidad de realizar cambios en las aplicaciones que usan las bases, pasando por tener que reeditar o cambiar casi siempre la mayoría de los procedimientos almacenados ya probados.
Es siempre mejor prepararse para el peor escenario de funcionamiento, ya que eventualmente el peor escenario (la experiencia me lo indica), suele ser aún peor de lo imaginado.
Como sugerencia, puntualmente respecto a los INT, si el campo en cuestión es un ID autoincremental, usa siempre como mínimo INT. Es muy fácil quedarse corto en ese caso.
El resto, depende del analisis, pero siempre piensa qué es lo peor que puede pasar.

[neodani]

Iniciado por gnzsoloyo

No perjudica ni corrompe. Lo único que sucede es que se debe evitar modificar la estructura de una base de datos cuando la base ya está en funcionamiento, por los múltiples problemas que eso produce.
Entiéndase por problemas desde incompatibilidad de los backups realizados con anterioridad, hasta la necesidad de realizar cambios en las aplicaciones que usan las bases, pasando por tener que reeditar o cambiar casi siempre la mayoría de los procedimientos almacenados ya probados.
Es siempre mejor prepararse para el peor escenario de funcionamiento, ya que eventualmente el peor escenario (la experiencia me lo indica), suele ser aún peor de lo imaginado.
Como sugerencia, puntualmente respecto a los INT, si el campo en cuestión es un ID autoincremental, usa siempre como mínimo INT. Es muy fácil quedarse corto en ese caso.
El resto, depende del analisis, pero siempre piensa qué es lo peor que puede pasar.

Muchas gracias gnzsoloyo por la información