¿Qué tipo de datos se debe usar para almacenar números de teléfono en SQL Server 2005?

Question

Necesito almacenar los números de teléfono en una tabla. Por favor sugiérame qué tipo de datos debería usar? Espera. Siga leyendo antes de presionar responder ...

Este campo debe indexarse ​​en gran medida, ya que los representantes de ventas pueden usar este campo para buscar (incluida la búsqueda de caracteres).

A partir de ahora, esperamos que los números de teléfono vengan en una variedad de formatos (desde un archivo XML). ¿Debo escribir un analizador para convertirlo a un formato uniforme? Puede haber millones de datos (con duplicados) y no quiero atar a los recursos del servidor (en actividades como el procesamiento previo demasiado) cada vez que alguna fuente de datos llega a través ..

Cualquier sugerencia es bienvenida ..

Actualización: No tengo control sobre los datos fuente. Solo que la estructura del archivo xml es estándar. Me gustaría mantener el análisis de xml al mínimo. Una vez que está en la base de datos, la recuperación debe ser rápida. Una gran sugerencia que está sucediendo aquí es que incluso debería funcionar con la función Autocompletar de Ajax (para que los representantes de ventas puedan ver los que coinciden de inmediato). ¡¡DIOS MIO!!

Answer 1

¿Esto incluye:

• números internacionales?
• ¿Extensiones?
• Otra información además del número real (como "preguntar por Bobby")?

Si todos estos son no, usaría un campo de 10 caracteres y eliminaría todos los datos no numéricos. Si el primero es un sí y los otros dos son no, usaría dos campos varchar (50), uno para la entrada original y otro con todos los datos no numéricos seccionados y utilizados para la indexación. Si 2 o 3 son sí, creo que haré dos campos y algún tipo de analizador loco para determinar qué es la extensión u otros datos y tratarlo adecuadamente. Por supuesto, podrías evitar la 2da columna haciendo algo con el índice donde se eliminen los caracteres adicionales al crear el índice, pero solo crearía una segunda columna y probablemente eliminaría los caracteres con un disparador.

Actualización: para resolver el problema de AJAX, puede que no sea tan malo como cree. Si esto es realísticamente la forma principal en que se hace algo en la tabla, almacene solo los dígitos en una columna secundaria como dije, y luego haga que el índice para esa columna sea el agrupado.

Answer 2

nvarchar con preprocesamiento para estandarizarlos tanto como sea posible. Probablemente quiera extraer extensiones y almacenarlas en otro campo.

Answer 3

Normalice los datos y almacénelos como varchar. La normalización podría ser difícil.

Eso debería ser un golpe de una sola vez. Luego, cuando aparece un nuevo registro, lo está comparando con datos normalizados. Debería ser muy rápido.

Answer 4

Probablemente me esté olvidando lo obvio aquí, pero ¿no le bastaría con un varchar el tiempo suficiente para que funcione su número de teléfono esperado más largo?

Si am falta algo obvio, me gustaría que si alguien señalarlo ...

Answer 5

utilizar un campo varchar con una restricción de longitud.

Answer 6

Yo usaría un varchar (22). Lo suficientemente grande como para contener un número de teléfono de América del Norte con extensión. Desearía eliminar todos los repugnantes caracteres '(', ')', '-' o simplemente analizarlos en un formato uniforme.

Alex

Answer 7

uso CHAR (10), si está almacenando los Estados Unidos sólo los números de teléfono. Elimina todo menos los dígitos.

Answer 8

SQL Server 2005 está bastante bien optimizado para consultas de subcadenas para texto en campos varchar indexados. Para 2005, introdujeron nuevas estadísticas en el resumen de cadenas para los campos de índice. Esto ayuda significativamente con la búsqueda de texto completo.

Answer 9

Usamos varchar (15) y sin duda el índice en ese campo.

La razón es que las normas internacionales pueden soportar hasta 15 dígitos

Wikipedia - Telephone Number Formats

Si apoyas números internacionales, recomiendo el almacenamiento por separado de un Código Código o País Zona Mundial a mejores consultas de filtro de modo que no se encuentre analizando y verificando la longitud de los campos de su número de teléfono para limitar las llamadas devueltas a EE. UU. por ejemplo

Answer 10

Dado que necesita acomodar muchos formatos diferentes de números de teléfono (y probablemente incluya cosas como extensiones, etc.) puede ma Tiene más sentido simplemente tratarlo como lo haría con cualquier otro varchar. Si pudiera controlar la entrada, podría tomar una serie de enfoques para hacer que los datos sean más útiles, pero no suenan de esa manera.

Una vez que decida simplemente tratarlo como cualquier otra cadena, puede enfocarse en superar los problemas inevitables con respecto a datos incorrectos, formateo misterioso de números de teléfono y cualquier otra cosa que aparezca. El desafío será construir una buena estrategia de búsqueda para los datos y no cómo la almacenas en mi opinión. Siempre es una tarea difícil tener que lidiar con una gran cantidad de datos que no tienes control sobre la recopilación.

Answer 11

Use SSIS para extraer y procesar la información. De esta forma tendrá el procesamiento de los archivos XML separados de SQL Server. También puede hacer las transformaciones de SSIS en un servidor por separado si es necesario. Almacene los números de teléfono en un formato estándar usando VARCHAR. NVARCHAR sería innecesario ya que estamos hablando de números y tal vez un par de otros caracteres, como '+', '', '(', ')' y '-'.

Answer 12

usando varchar es bastante ineficiente. use el tipo de dinero y cree un tipo de usuario declarado "número de teléfono" y cree una regla para permitir solo números positivos.

si lo declara como (19,4) incluso puede almacenar una extensión de 4 dígitos y ser lo suficientemente grande para números internacionales, y solo toma 9 bytes de almacenamiento. Además, los índices son rápidos.

Answer 13

Es bastante común usar una "x" o "ext" para indicar extensiones, así que permita 15 caracteres (para soporte internacional completo) más 3 (para "ext") más 4 (para la extensión en sí) dando un un total de 22 caracteres Eso debería mantenerte a salvo.

Alternativamente, normalice la entrada para que cualquier "ext" se traduzca a "x", dando un máximo de 20.

Answer 14

Me doy cuenta de que este hilo es viejo, pero vale la pena mencionar la ventaja de almacenarlo como un tipo numérico para el formato, específicamente en .NET framework.

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string 

Answer 15

Siempre es mejor tener tablas separadas para varios valores atributos como el número de teléfono.

Como no tiene control sobre los datos fuente, puede analizar los datos del archivo XML y convertirlos al formato adecuado para que no haya problemas con los formatos de un país en particular y almacenarlos en un archivo separado tabla para que indización y recuperación sean ambos eficaces.

Gracias.