¿Qué tipo de datos se debe usar para almacenar números de teléfono en SQL Server 2005?
Necesito almacenar números de teléfono en una mesa. Por favor, sugiera qué tipo de datos debo usar? Espere. Por favor, siga leyendo antes de pulsar respuesta ..
Este campo debe ser indexado en gran medida, ya que los Representantes de ventas pueden usar este campo para la búsqueda (incluida la búsqueda de caracteres comodín).
A partir de ahora, esperamos que los números de teléfono vengan en varios formatos (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 comprometer los recursos del servidor (en actividades como preprocesar demasiado) cada vez que se reciban datos de origen.
Cualquier sugerencia es bienvenida ..
Actualización: No tengo control sobre los datos de origen. Sólo que la estructura del archivo xml es estándar. Quisiera mantener el análisis xml al mínimo. Una vez que está en la base de datos, la recuperación debe ser rápida. Una sugerencia loca por aquí es que incluso debería funcionar con la función Autocompletar de Ajax (para que los Representantes de ventas puedan ver los correspondientes de inmediato). ¡¡DIOS MIO!!
¿Esto incluye:
- ¿Números internacionales?
- Extensiones?
- ¿Otra información además del número real (como "pedir 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 con bandas y utilizados para la indexación. Si 2 o 3 son sí, creo que haría dos campos y algún tipo de analizador loco para determinar qué es la extensión u otros datos y tratarlos adecuadamente. Por supuesto, podría evitar la segunda columna haciendo algo con el índice donde elimina los caracteres adicionales al crear el índice, pero yo solo haría una segunda columna y probablemente eliminaría los caracteres con un activador.
Actualización: para solucionar el problema AJAX, puede que no sea tan malo como crees. Si esto es realmente la forma principal en que se hace algo a 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.
Utilizamos varchar (15) y ciertamente indizamos 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, recomiendo el almacenamiento por separado de un Código de Zona Mundial o Código 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 solo almacena números de teléfono de EE. UU. Eliminar todo menos los dígitos.
Probablemente me esté perdiendo lo obvio aquí, pero ¿no funcionaría bien una varchar el tiempo suficiente para que su número de teléfono más esperado?
Si yo estoy falta algo obvio, me encantaría que alguien lo señalara ...
Yo usaría un varchar (22). Lo suficientemente grande como para mantener un número de teléfono norteamericano con extensión. Desearía eliminar todos los desagradables caracteres '(', ')', '-', o simplemente analizarlos en un formato uniforme.
Alex
el uso de varchar es bastante ineficiente. use el tipo de dinero y cree un tipo declarado por el usuario "número de teléfono" a partir de él, 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 los números internacionales, y solo requiere 9 bytes de almacenamiento. Además, los índices son rápidos.
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 cadena para los campos de índice. Esto ayuda significativamente con la búsqueda de texto completo.
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 propia extensión) 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.
nvarchar con preprocesamiento para estandarizarlos tanto como sea posible. Probablemente querrá extraer extensiones y almacenarlas en otro campo.
Normalice los datos y luego guárdelos como varchar. Normalizar puede ser complicado.
Eso debería ser un golpe de una sola vez. Luego, a medida que entra un nuevo registro, lo está comparando con los datos normalizados. Debería ser muy rápido.
Utilice un campo varchar con una restricción de longitud.
Ya que necesita acomodar muchos formatos de números de teléfono diferentes (y probablemente incluir cosas como extensiones, etc.) puede tener más sentido tratarlos 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 suena de esa manera.
Una vez que decida simplemente tratarlo como cualquier otra cadena, puede concentrarse en superar los problemas inevitables relacionados con los datos incorrectos, el formateo de números de teléfonos misteriosos y cualquier otra cosa que surja. El desafío será construir una buena estrategia de búsqueda para los datos y no cómo los almacena, en mi opinión. Siempre es una tarea difícil tener que lidiar con una gran cantidad de datos que no tuvo control sobre la recopilación.
Utilice SSIS para extraer y procesar la información. De esa manera, tendrá el procesamiento de los archivos XML separados de SQL Server. También puede hacer las transformaciones de SSIS en un servidor 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 '-'.
Me doy cuenta de que este hilo es antiguo, pero vale la pena mencionar la ventaja de almacenar como un tipo numérico para propósitos de formato, específicamente en el marco .NET.
IE
.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
Siempre es mejor tener tablas separadas para atributos de valor múltiple 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 almacenarlo en una tabla separada para que Tanto la indexación como la recuperación serán eficientes .
Gracias.