Tipo de datos para el número de teléfono: VARCHAR, INT o BIGINT?

Así que esta será la pregunta ficticia del año, pero tengo que preguntar ya que no es la primera vez que paso por esto. Eche un vistazo a la siguiente definición de tabla:

Eche un vistazo a la columna from_numberque es una en VARCHAR(45)este momento pero contendrá un número de teléfono. Como no sé cuántos números podría tener un teléfono en todo el mundo, estoy tratando de cubrir casi todos. Quiero mantener la integridad de la base de datos tanto como sea posible, así que creo VARCHARque no es un tipo adecuado para mantener este tipo de información, tal vez me equivoque, me dices, así que estoy pensando en cambiar INTo incluso BIGINT.

Cuando defino una columna en Workbench, debo especificar el número entre paréntesis, ()no en todos los casos, sino en los que mencioné anteriormente. Entonces, si hago esto: BIGINT()recibí este error:

Lo que me guía a leer un poco sobre este tipo de MySQL aquí . Básicamente la información es esta:

Un gran número entero. ... El rango sin signo es de 0 a 18446744073709551615.

Lo que me hace preguntar: qué valor debo establecer para paréntesis cuando estoy definiendo un BIGINT()tipo. (Estoy usando BIGINT porque no sé si INT puede contener tantos números como podría tener un teléfono, tal vez también estoy equivocado). ¿Cuál es la forma correcta de crear | diseñar una columna en las bases de datos MariaDB / MySQL?

De todos modos, me gustaría saber su opinión, experiencia y, por supuesto, me gustaría obtener una respuesta.

Nota: Estoy usando la última edición de MySQL Workbench para crear el diagrama ER. Estoy usando también MariaDB 10.0.x

¿Cómo manejaría un número de teléfono con una extensión, como "+ 1-000-000-0000 ext 1234"?

Tenga en cuenta que el "+" indica que se deben aplicar las reglas de marcado internacional; entonces, desde América del Norte, el sistema conoce automáticamente "011" frente a llamadas internacionales, etc.

Además, ¿qué pasa con los números de teléfono como "1-800-DBA-HELP"?

Normalmente almacenaba números de teléfono como texto. Dicho esto, realmente depende de cuán crítica sea la columna de su número de teléfono. Si está ejecutando marcadores automáticos desde esa columna, entonces realmente querrá asegurarse de que solo se incluyan números y que los datos representen números de teléfono bien formados.

Puede tener columnas separadas para extensiones y números de teléfono que tienen texto, como el ejemplo "1-800-DBA-HELP" que proporcioné.

Anteriormente estaba escrito:

"Con MariaDB podría usar un computedcampo para extraer solo los dígitos de un marcador automático. También funciona para MySQL 5.7".

En respuesta a la pregunta del OP sobre esto ("¿puedes explicar un poco qué me estás diciendo?"), Aquí hay una explicación.

Muchos sistemas de bases de datos ahora han introducido esta característica. Estos son campos que se conocen de diversas maneras como " computed", " virtual" o " generated" que se derivan de valores en otros campos. El poder de esta función variará dependiendo de su RDBMS. Sé que Oracle, Firebird, MariaDB y ahora MySQL 5.7 los tienen. Otros probablemente también lo hagan.

Un ejemplo fácil sería tener una columna de apellido y una columna calculada que "almacene" (recuerde, pueden ser virtuales, es decir, calculadas sobre la marcha, o pueden almacenarse físicamente en el disco) el apellido como todas las mayúsculas, haciendo así buscando más fácil De esa manera solo tiene que buscar en CAPs (usando, digamos, LIKE), sabiendo que los datos que se buscan en [ computed| virtualEl | generated] campo está en texto en mayúscula.

El concepto para MySQL 5.7 se explica aquí y aquí . Ha estado en MariaDB por un poco más de tiempo y el concepto también se explica aquí . Aquí se sugieren algunos usos posibles , pero en realidad solo está limitado por su imaginación. Pueden verse como un sustituto conveniente (y menos propenso a errores) para los desencadenantes.

Para su caso de uso particular, puede derivar un número marcado de un campo de texto "+" -> "00" (o cualquiera que sea su código de marcación internacional). Solo un pensamiento.

Hmm Los números de teléfono están hechos de números. El uso de varchar permite al usuario almacenar cualquier tipo de formato, con (o no, con - o. Y rápidamente crea un desastre con sus datos. Un formato de número de teléfono depende del "país", la máscara debe estar vinculada al país. Extensión es una extensión y es opcional, por lo que debe almacenarse en un "campo de extensión" (int también). Para 1-800-DBA-HELP, lo convertiría sobre la marcha y almacenaría el número real. Si realmente necesita estos número de teléfono legible para humanos, guárdelo en un campo varchar separado.

Por lo general, guardo los números de teléfono en texto simple . El formateo y la visualización lo dejan al código del cliente.

Aquí, más que, ¿cómo almacenas? lo que vas a hacer con ese número de teléfono es realmente importante.

Si su empresa desea realizar llamadas salientes desde su sistema, la aplicación extraerá solo números. Si su empresa desea realizar llamadas internacionales , almacene el código de país y el código de área en columnas separadas.

Si su empresa desea generar informes , la aplicación se formateará y mostrará con extensión y números por separado.

Según tengo entendido, diseñar un modelo de datos universal para un número de teléfono no es una buena idea. Cada país tiene diferentes números, extensiones y códigos de área además del código de país. Además, llegué a saber que algunos países no tienen código de área.

Es posible que esto no responda a su pregunta, pero ayudará a ampliar nuestra comprensión. Gracias.