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

Question

Necesito almacenar números de teléfono en una tabla.Sugiera qué tipo de datos debo utilizar.Esperar.Siga leyendo antes de responder.

Este campo debe indexarse ​​en gran medida, ya que los representantes de ventas pueden utilizarlo para realizar búsquedas (incluida la búsqueda de caracteres comodín).

A partir de ahora, esperamos que los números de teléfono vengan en varios formatos (a partir de un archivo XML).¿Tengo que escribir un analizador para convertir a un formato uniforme?Podría haber millones de datos (con duplicados) y no quiero ocupar demasiado los recursos del servidor (en actividades como el preprocesamiento) cada vez que llegan algunos datos de origen.

Cualquier sugerencia es bienvenida..

Actualizar: No tengo control sobre los datos de origen.Solo que la estructura del archivo xml es estándar.Me gustaría mantener el análisis xml al mínimo.Una vez que esté en la base de datos, la recuperación debería ser rápida.Una sugerencia loca que se está dando por aquí es que incluso debería funcionar con la función Autocompletar Ajax (para que los representantes de ventas puedan ver los que coinciden inmediatamente).¡¡DIOS MÍO!!

Answer 1

¿Esto incluye:

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

Si todo esto es negativo, usaría un campo de 10 caracteres y eliminaría todos los datos no numéricos.Si el primero es 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 separados y usados ​​para la indexación.Si 2 o 3 son afirmativos, creo que haría dos campos y algún tipo de analizador loco para determinar qué es una extensión u otros datos y tratarlos adecuadamente.Por supuesto, podría evitar la segunda columna haciendo algo con el índice que elimine los caracteres adicionales al crear el índice, pero yo simplemente haría una segunda columna y probablemente eliminaría los caracteres con un disparador.

Actualizar:Para solucionar el problema de AJAX, puede que no sea tan malo como cree.Si, de manera realista, esta es 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 de esa columna sea el agrupado.

Answer 2

Usamos varchar(15) y ciertamente indexamos en ese campo.

La razón es que los estándares internacionales pueden admitir hasta 15 dígitos.

Wikipedia - Formatos de números de teléfono

Si admite números internacionales, le recomiendo almacenar por separado un código de zona mundial o un código de país para filtrar mejor las consultas y no tener que analizar y verificar la longitud de los campos de su número de teléfono para limitar las llamadas devueltas a EE. UU. para ejemplo

Answer 3

Utilice CHAR(10) si está almacenando únicamente números de teléfono de EE. UU.Elimina todo menos los dígitos.

Answer 4

Probablemente me estoy perdiendo lo obvio aquí, pero ¿no funcionaría bien un varchar lo suficientemente largo para su número de teléfono esperado más largo?

Si yo soy Me falta algo obvio, me encantaría que alguien lo señalara...

Answer 5

Yo usaría un varchar (22).Lo suficientemente grande como para albergar un número de teléfono norteamericano con extensión.Debería eliminar todos los caracteres desagradables '(', ')', '-' o simplemente analizarlos todos en un formato uniforme.

Alex

Answer 6

SQL Server 2005 está bastante bien optimizado para consultas de subcadenas de 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 7

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

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

Answer 8

nvarchar con preprocesamiento para estandarizarlos lo más posible.Probablemente quieras extraer extensiones y almacenarlas en otro campo.

Answer 9

Normalice los datos y luego guárdelos como varchar.La normalización podría ser complicada.

Eso debería ser un éxito de una sola vez.Luego, cuando llega un nuevo registro, lo compara con datos normalizados.Debería ser muy rápido.

Answer 10

Dado que necesita adaptarse a muchos formatos de números de teléfono diferentes (y probablemente incluir elementos como extensiones, etc.), puede que tenga más sentido tratarlo como lo haría con cualquier otro varchar.Si pudiera controlar la entrada, podría adoptar varios enfoques para hacer que los datos sean más útiles, pero no parece así.

Una vez que decidas tratarlo simplemente como cualquier otra cadena, puedes concentrarte en superar los problemas inevitables relacionados con datos incorrectos, el formato misterioso de los números de teléfono y cualquier otra cosa que surja.En mi opinión, el desafío será construir una buena estrategia de búsqueda para los datos y no cómo almacenarlos.Siempre es una tarea difícil tener que lidiar con una gran cantidad de datos sobre los cuales no se tenía control sobre su recopilación.

Answer 11

Utilice SSIS para extraer y procesar la información.De esa forma tendrás el procesamiento de los archivos XML separados de SQL Server.También puede realizar las transformaciones SSIS en un servidor independiente 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 de un par de caracteres más, como '+', ' ', '(', ')' y '-'.

Answer 12

Usar una varchar campo con una restricción de longitud.

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í), lo que da 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 antiguo, pero vale la pena mencionar la ventaja de almacenar como tipo numérico para fines de formato, específicamente en .NET Framework.

ES DECIR

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

Answer 15

Siempre es mejor tener tablas separadas para atributos con múltiples valores, como el número de teléfono.

Como no tiene control sobre los datos de origen, puede analizar los datos del archivo XML y convertirlos al formato adecuado para que no haya ningún problema con los formatos de un país en particular y almacenarlos en una tabla separada para que Tanto la indexación como la recuperación serán eficientes..

Gracias.