Qual tipo de dados deve ser usado para armazenar números de telefone no SQL Server 2005?

Question

Preciso armazenar números de telefone em uma tabela.Por favor, sugira qual tipo de dados devo usar?Espere.Por favor, leia antes de responder.

Este campo precisa ser fortemente indexado, pois os representantes de vendas podem usá-lo para pesquisa (incluindo pesquisa de caracteres curinga).

A partir de agora, esperamos que os números de telefone venham em vários formatos (a partir de um arquivo XML).Preciso escrever um analisador para converter para um formato uniforme?Pode haver milhões de dados (com duplicatas) e não quero ocupar os recursos do servidor (em atividades como pré-processamento demais) toda vez que algum dado de origem chega.

Qualquer sugestão é bem vinda..

Atualizar: Não tenho controle sobre os dados de origem.Só que a estrutura do arquivo xml é padrão.Gostaria de manter a análise de xml no mínimo.Uma vez no banco de dados, a recuperação deve ser rápida.Uma sugestão maluca que está acontecendo por aqui é que ele deve funcionar até com o recurso Ajax AutoComplete (para que os representantes de vendas possam ver os correspondentes imediatamente).OH MEU DEUS!!

Answer 1

Isso inclui:

• Números internacionais?
• Extensões?
• Outras informações além do número real (como "pergunte pelo Bobby")?

Se tudo isso for não, eu usaria um campo de 10 caracteres e retiraria todos os dados não numéricos.Se o primeiro for sim e os outros dois não, eu usaria dois campos varchar(50), um para a entrada original e outro com todos os dados não numéricos distribuídos e usados ​​para indexação.Se 2 ou 3 forem sim, acho que faria dois campos e algum tipo de analisador maluco para determinar o que é extensão ou outros dados e lidar com isso de maneira adequada.É claro que você poderia evitar a segunda coluna fazendo algo com o índice onde ele retira os caracteres extras ao criar o índice, mas eu apenas faria uma segunda coluna e provavelmente removeria os caracteres com um gatilho.

Atualizar:para resolver o problema do AJAX, pode não ser tão ruim quanto você pensa.Se esta for realisticamente a principal maneira de fazer qualquer coisa na tabela, armazene apenas os dígitos em uma coluna secundária, como eu disse, e então torne o índice dessa coluna agrupado.

Answer 2

Usamos varchar(15) e certamente indexamos nesse campo.

A razão é que os padrões internacionais podem suportar até 15 dígitos

Wikipedia - Formatos de números de telefone

Se você oferece suporte a números internacionais, recomendo o armazenamento separado de um código de zona mundial ou código de país para filtrar melhor as consultas, de modo que você não tenha que analisar e verificar o comprimento dos campos do seu número de telefone para limitar as chamadas retornadas para os EUA para exemplo

Answer 3

Use CHAR(10) se estiver armazenando apenas números de telefone dos EUA.Remova tudo, menos os dígitos.

Answer 4

Provavelmente estou perdendo o óbvio aqui, mas um varchar longo o suficiente para o seu número de telefone mais longo esperado não funcionaria bem?

Se eu sou faltando algo óbvio, eu adoraria se alguém apontasse isso ...

Answer 5

Eu usaria um varchar(22).Grande o suficiente para armazenar um número de telefone norte-americano com extensão.Você gostaria de remover todos os caracteres desagradáveis ​​'(', ')', '-' ou apenas analisá-los em um formato uniforme.

Alex

Answer 6

O SQL Server 2005 é muito bem otimizado para consultas de substring para texto em campos varchar indexados.Em 2005, eles introduziram novas estatísticas no resumo de strings para campos de índice.Isso ajuda significativamente na pesquisa de texto completo.

Answer 7

usar varchar é bastante ineficiente.use o tipo money e crie um tipo declarado pelo usuário "phonenumber" a partir dele e crie uma regra para permitir apenas números positivos.

se você declarar como (19,4), poderá até armazenar um ramal de 4 dígitos e ser grande o suficiente para números internacionais, ocupando apenas 9 bytes de armazenamento.Além disso, os índices são rápidos.

Answer 8

nvarchar com pré-processamento para padronizá-los tanto quanto possível.Você provavelmente desejará extrair extensões e armazená-las em outro campo.

Answer 9

Normalize os dados e armazene-os como um varchar.Normalizar pode ser complicado.

Isso deve ser um sucesso único.Então, quando um novo registro chega, você o compara com dados normalizados.Deve ser muito rápido.

Answer 10

Como você precisa acomodar muitos formatos diferentes de números de telefone (e provavelmente incluir coisas como extensões, etc.), pode fazer mais sentido tratá-lo como faria com qualquer outro varchar.Se você pudesse controlar a entrada, poderia adotar diversas abordagens para tornar os dados mais úteis, mas não parece ser assim.

Depois de decidir simplesmente tratá-lo como qualquer outra string, você pode se concentrar em superar os problemas inevitáveis ​​relacionados a dados incorretos, formatação misteriosa de números de telefone e tudo o mais que surgir.O desafio estará em construir uma boa estratégia de busca para os dados e não em como armazená-los, na minha opinião.É sempre uma tarefa difícil lidar com uma grande pilha de dados sobre os quais você não tem controle.

Answer 11

Use o SSIS para extrair e processar as informações.Dessa forma você terá o processamento dos arquivos XML separados do SQL Server.Você também pode fazer as transformações do SSIS em um servidor separado, se necessário.Armazene os números de telefone em um formato padrão usando VARCHAR.NVARCHAR seria desnecessário, pois estamos falando de números e talvez alguns outros caracteres, como '+', ' ', '(', ')' e '-'.

Answer 12

Use um varchar campo com restrição de comprimento.

Answer 13

É bastante comum usar um "x" ou "ext" para indicar extensões, portanto permita 15 caracteres (para suporte internacional completo) mais 3 (para "ext") mais 4 (para a própria extensão) dando um total de 22 caracteres .Isso deve mantê-lo seguro.

Alternativamente, normalize na entrada para que qualquer "ext" seja traduzido para "x", dando um máximo de 20.

Answer 14

Sei que este tópico é antigo, mas vale a pena mencionar a vantagem de armazenar como um tipo numérico para fins de formatação, especificamente no .NET framework.

Ou seja

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

Answer 15

É sempre melhor ter tabelas separadas para atributos com vários valores, como número de telefone.

Como você não tem controle sobre os dados de origem, você pode analisar os dados do arquivo XML e convertê-los no formato adequado para que não haja nenhum problema com os formatos de um determinado país e armazená-los em uma tabela separada para que indexação e recuperação serão eficientes.

Obrigado.