tipo de datos mysql para número de teléfono y dirección

En realidad se puede utilizar un varchar para un número de teléfono. No necesita un int porque no va a realizar aritmética sobre los números.

Almacenarlos como dos campos para números de teléfono - un "número" y una "máscara" como TinyText tipos que no necesitan más de 255 elementos.

Antes de almacenar los archivos analizamos el número de teléfono para obtener el formato que se ha utilizado y que crea la máscara, luego almacenamos el número a solo dígitos, por ejemplo,

Entrada: (0123) 456 7890
Número: 01234567890
Máscara: (nnnn)_nnn_nnnn

Teóricamente esto nos permite realizar búsquedas de comparación en el campo de Número, como obtener todos los teléfonos números que comienzan con un código de área específico, sin tener que preocuparse de cómo fue introducido por los usuarios

Suelo almacenar números de teléfono como un BIGINT en formato E164.

E164 nunca comienza con un 0, siendo los primeros dígitos el código del país.

+441234567890
+44 (0)1234 567890
01234 567890

Etc. se almacenaría como 441234567890.

Usaría un varchar para los números de teléfono. de esa manera también puede almacenar + y (), que a veces se ve en números tel (como usted mismo mencionó). y no tienes que preocuparte por usar todos los bits en enteros.

No estoy seguro de si es una buena idea usar enteros en absoluto. Algunos números pueden contener caracteres especiales (#como parte de la extensión, por ejemplo) que también debería ser capaz de manejar. Así que sugeriría usar varchars en su lugar.

Si el almacenamiento de menos de 1 mil registros, y el alto rendimiento no es un problema ir para varchar(20)/char(20) de lo contrario he encontrado que para almacenar incluso 100 millones de teléfonos de negocios globales o teléfonos personales, int es mejor. Razón: tecla más pequeña - > mayor velocidad de lectura / escritura, también el formato puede permitir duplicados.

1 teléfono en char ( 20) = 20 bytes vs 8 bytes bigint (o 10 vs 4 bytes int para teléfonos locales, hasta 9 dígitos), menos entradas pueden ingresar el bloque de índice = > más bloques = > más búsquedas, ver this para más información (escrito para Mysql pero debería ser cierto para otras bases de datos Relacionales).

Aquí hay un ejemplo de tablas telefónicas:

CREATE TABLE `phoneNrs` (   
    `internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
    `format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
    PRIMARY KEY (`internationalTelNr`)
    )
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin

O con procesamiento / división antes de insertar (2+2+4+1 = 9 bytes)

CREATE TABLE `phoneNrs` (   
    `countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
    `countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
    `localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
    `localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
    PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`)  -- ordered for fast inserts
) 
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;

También "el número de teléfono no es un número", en mi opinión es relativo al tipo de números de teléfono. Si estamos hablando de una agenda interna móvil, entonces las cadenas están bien, ya que el usuario puede desear almacenar Códigos Hash GSM. Si almacenando E164 teléfonos, bigint es la mejor opción.

Considere la posibilidad de normalizar al formato E. 164. Para un soporte internacional completo, necesitarías un VARCHAR de 15 dígitos.

Consulte La recomendación de Twilio para obtener más información sobre la localización de números de teléfono.

INT(10) no significa un número de 10 dígitos, significa un entero con un ancho de pantalla de 10 dígitos. El valor máximo para un INT en MySQL es 2147483647 (o 4294967295 si no está firmado).

Puede usar un BIGINT en lugar de INT para almacenarlo como numérico. Utilizar BIGINT le ahorrará 3 bytes por fila sobre VARCHAR(10).

Para almacenar "País + área + número por separado". Puede intentar usar un VARCHAR (20), esto le permite almacenar números de teléfono internacionales correctamente, si es necesario.

Varchar o text deberían ser los mejores tipos de datos para almacenar números móviles, supongo.