Columnas de números de teléfono en una base de datos

Question

En las últimas 3 empresas en las que he trabajado, las columnas del número de teléfono son de tipo varchar (n). La razón es que podrían querer almacenar extensiones (extensión 333). Pero en todos los casos, los caracteres "-" se eliminan al insertar y actualizar. No entiendo por qué los caracteres ".ext" están bien para almacenar, pero no el carácter "-". ¿Alguien más ha visto esto y qué explicación puedes pensar para hacerlo de esta manera? Si todo lo que desea almacenar son los números, ¿no es mejor que use un campo int? Por el contrario, si desea almacenar el número como una cadena/varchar, ¿por qué no mantener todos los caracteres y no molestarse con el formateo en la pantalla y la limpieza al escribir?

También estoy interesado en conocer otras formas en que se implementa el almacenamiento de números de teléfono en otros lugares.

Answer 1

un punto con números de teléfono de almacenamiento es una de las principales 0.

por ejemplo: 01202 8765432

en una columna int, el 0 será despojado de, lo que hace que el número de teléfono válido.

Me gustaría aventurar una respuesta a - ser canjeados por espacios es porque ellos no significan realmente nada

por ejemplo: 123-456-789 = 123 456 789 = 123456789

Answer 2

prueba rápida: vas para sumar/restar/multiplicar/dividir números de teléfono? Nop. De manera similar a los SSN, los números de teléfono son datos discretos que pueden contener números reales, por lo que un tipo de cadena es probablemente el más apropiado.

Answer 3

Eliminar algunos caracteres y permitir que otros puedan tener un impacto si la tabla de la base de datos va a conducir otro sistema, p. Telefonía IP de algún tipo. Dependiendo de los sistemas involucrados, puede ser legítimo tener etc.333 como sufijo, mientras que los desarrolladores pueden no haber contabilizado "-" en la cadena (y sí, estoy adivinando aquí ...)

As para almacenar como un varchar en lugar de un int, esto es simplemente sentido común para mí. Como se mencionó anteriormente, los ceros a la izquierda pueden ser despojados en un campo int, la consulta en un campo int puede realizar funciones matemáticas implícitas (que también podrían explicar la extracción del texto "-", no desea ingresar 555-1234 y tener almacenó como -679 ¿verdad?)

En resumen, no sé el razonamiento exacto, pero puedo deducir algunas posibilidades.

Answer 4

Personalmente, no quitaría ninguno de los caracteres, ya que dependiendo de dónde sea el número de teléfono, podría significar cosas diferentes. Deje el número de teléfono en el formato exacto en que fue ingresado, ya que obviamente esa es la forma en que la persona que lo ingresó está acostumbrada a verlo.

Answer 5

Optaría por almacenar los dígitos como una cadena y agregar los diversos "()" y "-" en mi código de visualización. Se vuelve más difícil con números internacionales. Lo manejamos teniendo varios formatos de visualización "internacionalizados" dependiendo del país.

Answer 6

Realmente no importa cómo lo almacene, , siempre que sea consistente. La norma es eliminar los caracteres de formato, pero también puede almacenar el código de país, el código de área, el intercambio y la extensión por separado si necesita consultar esos valores. Nuevamente, el requisito es que sea consistente; de ​​lo contrario, consultar es un PITA.

Answer 7

Lo que me gusta hacer si sé que los números de teléfono solo van a estar dentro de una región específica, como América del Norte, es cambiar la entrada en 4 campos. 3 para el código de área, 3 para el prefijo, 3 para la línea y tal vez 5 para la extensión.Luego inserto estos como 1 campo con '-' y tal vez una 'e' para designar la extensión. Cualquier búsqueda por supuesto también necesita seguir el mismo proceso. Esto garantiza que obtenga datos más regulares e incluso permite que se use el número para hacer una llamada de teléfono, una vez que se eliminan la extensión y la extensión. También puedo volver a los 4 campos originales fácilmente.

Answer 8

¡Buenas cosas! Parece que el punto principal es que el formato del número de teléfono no forma parte de los datos, sino que es un aspecto del país de origen. Sin embargo, al mantener la extensión como parte del número, uno podría estar rompiendo el modelo de separación del formato de los datos. Dudo que todos los países usen la misma sintaxis/formato para describir una extensión. Además, si la integración con un sistema telefónico es un requisito (posible), entonces podría ser mejor almacenar la extensión por separado y generar el mensaje como se espera. Pero Mark también señala que si eres coherente, probablemente no importe cómo lo almacenas, ya que también puedes consultarlo y procesarlo de manera consistente.

Gracias Eric por el enlace a la otra pregunta.

Answer 9

Otra razón por la que puedo pensar en no almacenar números de teléfono como 'números' sino como cadenas de caracteres, es a menudo suficiente parte de la pila de software que usaría para acceder a la base de datos (PHP, te estoy mirando) no admitiría números enteros lo suficientemente grandes (de forma nativa) para poder almacenar algunos de los números de teléfono más antiguos y/o exóticos.

Mayor número de 32 bits que pueden llevar, sin signo, es 4294967295. Eso no funcionaría para cualquier número de teléfono móvil de Rusia, tomar, por ejemplo, el número 4959261234.

Así que tiene usted mismo una inconveniente adicional de encontrar una manera de transportar datos numéricos de más de 32 bits. A pesar de que las bases de datos siempre han soportado enteros muy grandes, solo necesitas un enlace defectuoso en la cadena para obtener una parada espectacular. Como PHP, de nuevo.

Answer 10

Cuando un sistema telefónico automatizado usa un campo para hacer una llamada telefónica, es posible que no pueda decir qué caracteres debe usar y cuáles debe ignorar al marcar. Un ser humano puede ver un carácter "(" o ")" o "-" y saber que se consideran delimitadores que separan el código de área, npa y nxx del número de teléfono. Sin embargo, recuerde que cada personaje representa un patrón binario que, a menos que esté preprogramado para ignorar, se ingresaría mediante un marcador automático. Para explicar esto, es mejor almacenar el equivalente de solo los caracteres que un usuario presionaría en el auricular del teléfono y aún mejor que los valores individuales se almacenen en columnas separadas para que el marcador pueda usar campos individuales sin tener que analizar la cadena.

Incluso si no utiliza la automatización de marcación, es una buena práctica almacenar cosas que no necesita actualizar en el futuro. Es mucho más fácil agregar caracteres entre campos que quitarlos de cadenas.

En el comentario de utilizar un tipo de datos de cadena frente a entero como se indica anteriormente, las cadenas son la forma correcta de almacenar números de teléfono según las variaciones entre países. Sin embargo, hay una advertencia importante al respecto, ya que al agregar estadísticas para informar (es decir, SUMA de cuántos números o llamadas) las cadenas de caracteres son MUCHO más lentas de contar que los enteros. Para tener en cuenta esto, es importante agregar un número entero como columna de identidad que puede usar para contar en lugar del tipo de datos varchar o char field.