it-swarm-pt.tech

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

Eu preciso armazenar números de telefone em uma tabela. Por favor, sugira qual tipo de dados devo usar? Aguarde. Por favor, leia antes de você bater a resposta ..

Esse campo precisa ser indexado com muita intensidade, pois os representantes de vendas podem usar esse campo para pesquisar (incluindo a pesquisa de caracteres selvagens).

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

Qualquer sugestão é bem vinda ..

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

68
John

Isso inclui:

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

Se tudo isso não for, eu usaria um campo de 10 caracteres e removeria todos os dados não numéricos. Se o primeiro é um sim e os outros dois não, eu usaria dois campos varchar (50), um para a entrada original e um 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 louco para determinar o que é extensão ou outros dados e lidar com isso de forma apropriada. É claro que você poderia evitar a segunda coluna fazendo algo com o índice, onde ele remove os caracteres extras ao criar o índice, mas eu apenas criaria uma segunda coluna e provavelmente faria o decapeamento de caracteres com um gatilho.

Atualização: para resolver o problema AJAX, pode não ser tão ruim quanto você pensa. Se isso é 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 faça o índice dessa coluna, o agrupado.

50
Kearns

Usamos varchar (15) e certamente indexamos nesse campo.

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

Wikipedia - Formatos de números de telefone

Se você aceita números internacionais, recomendo o armazenamento separado de um Código da Zona Mundial ou Código do País para filtrar melhor as consultas, para que você não fique analisando e verificando a extensão dos campos do número de telefone para limitar as chamadas retornadas para os EUA. exemplo

33
Brad Osterloo

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

4
Joseph Bui

Eu provavelmente estou perdendo o óbvio aqui, mas não seria um varchar apenas o tempo suficiente para o seu maior número de telefone esperado funcionar bem?

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

3
cori

Eu usaria um varchar (22). Grande o suficiente para manter 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

3
Alex Fort

usar o varchar é bastante ineficiente. use o tipo de dinheiro e crie um tipo de usuário declarado "phonenumber", e crie uma regra para permitir somente números positivos.

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

2
fjleon

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

2
Joseph Daigle

É 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 extensão em si), fornecendo 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.

1
Rob G

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

1
John Sheehan

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

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

1
Iain Holder

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

1
user13270

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

Uma vez que você decida simplesmente tratá-la como qualquer outra string, você pode se concentrar em superar as inevitáveis ​​questões relacionadas a dados incorretos, formatação misteriosa de números de telefone e qualquer outra coisa que apareça. O desafio será construir uma boa estratégia de busca para os dados e não como você os armazena na minha opinião. É sempre uma tarefa difícil ter que lidar com uma grande pilha de dados que você não tinha controle sobre a coleta.

1
unicorn.ninja

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. O NVARCHAR seria desnecessário, já que estamos falando de números e talvez alguns outros caracteres, como '+', '', '(', ')' e '-'.

1
Magnus Johansson

Eu percebo que este segmento é antigo, mas vale a pena mencionar uma vantagem de armazenar como um tipo numérico para fins de formatação, especificamente no .NET framework.

IE

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

É 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, 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.

0
Jayghosh Wankar