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

tipos de datos sql (15)

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

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

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

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!!

Como necesita acomodar muchos formatos diferentes de números de teléfono (y probablemente incluya cosas como extensiones, etc.) puede tener más sentido 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 relacionados con los datos incorrectos, el misterioso formato del número 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.

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 total de 22 caracteres . Eso debería mantenerte a salvo.

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

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 abordar el problema de AJAX, puede que no sea tan malo como crees. 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.

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

ES DECIR

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

Normalice los datos y luego 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.

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

Si me falta algo obvio, me encantaría que alguien lo señale ...

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.

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

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

Wikipedia - Formatos de número de teléfono

Si admite números internacionales, le recomiendo el almacenamiento por separado de un código de zona mundial o de país para filtrar mejor las consultas 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. ejemplo

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

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 ''-''.

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

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

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

usar 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 declaras como (19,4) incluso puedes 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.

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 fuente, puede analizar los datos del archivo XML y convertirlos en el formato adecuado para que no haya problemas con los formatos de un país en particular y almacenarlos en una tabla separada para que la indexación y el la recuperación de ambos será eficiente .

Gracias.