problema guarar valor INT en phpMyAdmin

[worldPeace_Plis]

Hola amigos, tengo una duda y es que cuando estoy guardando valores directamente en phpmMyAdmin tengo una columna de telefono a la que le asigne un tipo numerico INT (10) NULL, asi es que se supone que esta limitada a 10 digitos, pero cuando estoy guardando valores me sustituye todos los numeros por 2147483647, por que? alguien que me pueda ayudar con esto?

Salu2!

[gnzsoloyo]

1) Los números de teléfono no se guardan como números sino como VARCHAR. Esto es simplemente porque de lo contrario hará desaparecer los ceros a la izquierda, que en ocasiones son necesarios (códigos de DDN, por ejemplo).
2) El (10) no representa la cantidad de dígitos posibles de ese número, sino el ancho del patron de representación para ajuste de texto. El valor máximo de un número está dado por su tipo de dato (TINYINT, SMALLINT, MEDIUMINT, INT BIGINT), ya que los números no se almacenan como cifras sino como binarios, usando entre 1 y 8 bytes según el tipo de columna.
Lo que tu estás haciendo es generando un desborde de rango, por eso te pone esa cifra. Un INT con signo tiene un rango de -2147483648 a 2147483647. Si le sumas uno más, cortará a esa cifra.

Según el manual de referencia:

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.

[worldPeace_Plis]

Oh! bien, no sabia lo de los limites o rangos de numero de int, tinyint,smallint etc
entonces si uso int cuyo limite es 2147483647 al guardar una cifra (telefono) con 4491234567 esto esta excedido, ok... comprendido

GRACIAS por la informacion!

[worldPeace_Plis]

Yo de nuevo. Me encontre con algo. Que tan recomendable es en cuanto a peso almacenar numeros en columnas de cadena con respecto a cols de tipo numerico:

"Cada digito incluido en una cadena ocupa un byte de espacio, en contraposicion a un campo numerico, que 1os almacena en bits. Asi mismo, la ordenacion de numeros almacenados en columnas de cadena puede generar resultados incoherentes."

Entonces me preguntaba si valdria guardar en un BIGINT (suponiendo que siempre tendre numeros 'telefonicos' de 10 digitos, incluyendo la lada, y si BIGINT admite de 0 a 18.446.744.073.709.551.615 (UNSIGNED) y requiere 8 bytes de espacio de
almacenamiento. Me imagino que especificar esta columna: tel BIGINT(10) admita 9999999999 como valor numerico limite, si esto es posible, entonces, que ocuparia mas espacio.

[gnzsoloyo]

Yo de nuevo. Me encontre con algo. Que tan recomendable es en cuanto a peso almacenar numeros en columnas de cadena con respecto a cols de tipo numerico:

No tiene ningún sentido, utilidad ni practicidad almacenar números como cadenas de texto.
Para citar tu propio ejemplo, para almacenar 9999999999 requieres un BIGINT, pero eso implica que en realidad estás usando 8 bytes, contra 10, así que en el peor de los casos ahorras un 20% de espacio poniéndolo como número.
No te olvides el principio básico: No guardas cifras. Guardas binarios, lo que implica que lo que guardas en realidad en un BIGINT al almacenar 9999999999 como número es 2540BE3FF en hexadecimal, o 112402761777 en octales, o bien 1001010100000010111110001111111111 en binario. En cualquier caso siguen siendo 8 bytes. Nada más, mientras que para almacenar "9999999999" requieres sólo en Hexa: 39393939393939393939.
Piensa esto: Si no ahorrases espacio y problemas almacenándolos como binarios, ¿no crees que las bases de datos financieras del mundo entero, no usarían esa forma para manejar las cifras? Es obvio entonces que es un sistema eficiente y efectivo a la hora de manejar datos numéricos...