É uma boa idéia usar uma coluna inteira para armazenar códigos postais dos EUA em um banco de dados?

StackOverflow https://stackoverflow.com/questions/893454

Pergunta

De primeira vista, parece que eu tenho duas opções básicas para armazenar ZIP códigos em um tabela de banco de dados:

  1. Text (provavelmente o mais comum), ou seja char(5) ou varchar(9) para apoiar +4 extensão
  2. numérico, isto é, de 32 bits número inteiro

Ambos iria satisfazer os requisitos dos dados, se assumirmos que não existem preocupações internacionais. No passado nós geralmente apenas ido a rota de texto, mas eu queria saber se alguém faz o contrário? Apenas a partir comparação breve parece que o método inteiro tem duas vantagens claras:

  • É, por meio de sua natureza, limitado automaticamente para valores numéricos somente (que, sem a validação do estilo de texto pode armazenar cartas e tais que não são, a meu conhecimento, sempre válida em um CEP). Este não significa que poderia / / deve renunciar validar a entrada do usuário como normal, embora!
  • Demora menos espaço, sendo 4 bytes (que deve ser suficiente até mesmo para códigos postais 9 dígitos) em vez de 5 ou 9 bytes.

Além disso, parece que ele não faria mal a saída de vídeo muito. É trivial tapa um ToString() em um valor numérico, use a manipulação de cadeia simples para inserir um hífen ou espaço ou o que quer para a extensão +4, e uso corda formatação para restaurar zeros à esquerda.

Existe alguma coisa que iria desencorajar usando int como um tipo de dados para nós só de ZIP códigos?

Foi útil?

Solução

Um código numérico ZIP é - em um pequeno caminho - enganosa.

Os números devem significar algo numérica . CEPs não adicionar ou subtrair ou participar em quaisquer operações numéricas. 12309 -. 12345 não computa a distância do centro de Schenectady para o meu bairro

Com certeza, para ZIP códigos, ninguém está confuso. No entanto, para outro número semelhante campos, pode ser confuso.

Desde ZIP códigos não são números - eles só acontecerá a ser codificado com um alfabeto restrito - eu sugiro evitar um campo numérico. A poupança de 1 byte não vale muito. E eu acho que esse significa é mais importante do que o byte.

Editar .

"Quanto a zeros à esquerda ..." é o meu ponto. Os números não têm zeros à esquerda. A presença de zeros à esquerda significativas em ZIP códigos é mais uma prova de que eles não estão numérico.

Outras dicas

Você vai códigos postais de sempre loja fora dos EUA? O Canadá é 6 caracteres com algumas letras. Eu costumo usar apenas um campo de 10 caracteres. O espaço em disco é barato, ter que refazer o seu modelo de dados é não.

Use uma string com validação. Zip códigos pode começar com 0, de modo numérico não é um tipo adequado. Além disso, isso se aplica perfeitamente aos códigos postais internacionais (por exemplo, no Reino Unido, que é de até 8 caracteres). No caso improvável de que os códigos postais são um gargalo, você pode limitá-lo a 10 caracteres, mas verificar a sua formatos de destino primeiro.

Aqui estão validação expressões regulares para o Reino Unido, EUA e Canadá.

Sim, você pode pad para obter os zeros à esquerda para trás. No entanto, você está teoricamente jogando fora informações que possam ajudar em caso de erros. Se alguém acha 1235 no banco de dados, é que originalmente 01235, ou tem outro dígito sido perdidas?

A melhor prática diz que você deve dizer o que você quer dizer. A CEP é um código, não um número. Você vai add / subtrair / multiplicar / dividir códigos postais? E a partir de uma perspectiva prática, é muito mais importante do que você está excluindo zips prolongados.

Normalmente, você usaria um tipo de dados não-numérica, como um varchar que permitiria mais tipos CEP. Se você está morto em conjunto permitindo apenas 5 dígitos [XXXXX] ou 9 dígitos [XXXXX-XXXX] códigos postais, você poderia, então, usar um char (5) ou char (10), mas eu não recomendo. Varchar é a escolha mais segura e mais saudável.

Edit: Também deve-se notar que, se você não planeja fazer cálculos numéricos no campo, você não deve usar um tipo de dados numéricos. CEP é um não um número no sentido de que você adicionar ou subtrair contra ela. É apenas uma cadeia que passa a ser composta tipicamente de números, então você deve se abster de utilizar tipos de dados numéricos para ele.

Do ponto de vista técnico, alguns pontos levantados aqui são bastante trivial. Eu trabalho com dados de endereço limpeza em um diário base - em especial os dados de endereço limpeza de todo o mundo. Não é uma tarefa trivial em qualquer trecho da imaginação. Quando se trata de zip códigos, você pode armazená-los como um inteiro, embora possa não ser "semanticamente" correta. O fato é que os dados são de uma forma numérica ou não, falando estritamente é numérica considerada em valor.

No entanto, a real desvantagem de armazená-los como tipos numéricos é que você vai perder a capacidade de facilmente ver se os dados foi digitado incorretamente (ou seja, se os valores em falta) ou se o sistema removido zeros à esquerda que levam a operações dispendiosas para validar códigos postais potencialmente inválidos que eram de outra maneira correta.

Também é muito difícil de forçar o usuário a dados corretos de entrada se uma das repercussões é um atraso de negócio. Os usuários muitas vezes não têm a paciência para inserir os dados corretos se não é imediatamente óbvio. Usando uma expressão regular é uma forma de garantir dados corretos, no entanto, se o usuário digita um valor que não se conforma e eles são exibidos um erro, eles podem simplesmente omitir este valor totalmente ou digitar algo que esteja de acordo, mas é de outra maneira incorreta. Um exemplo [usando códigos postais canadenses] é que muitas vezes você vê A0A 0A0 entrou que não é válido, mas está em conformidade com o regex para códigos postais canadenses. Mais frequentemente do que não, este é introduzido por usuários que são forçados a fornecer um código postal, mas eles não sabem nem o que é ou não tem tudo isso corrigir.

Uma sugestão é para validar o conjunto da entrada como uma unidade de validação de que o CEP está correto quando comparado com o resto do endereço. Se ele estiver incorreto, em seguida, oferecendo alternativas códigos postais válidos para o endereço irá torná-lo mais fácil para eles de dados válido de entrada. Da mesma forma, se o código postal é correto para o endereço, mas o número de rua está fora do domínio desse código postal, em seguida, oferecer números de rua alternativas para essa combinação CEP / rua.

A menos que você tem um requisito de negócio para realizar cálculos matemáticos em ZIP dados de código, não há nenhum ponto em usar um INT. Você está sobre engenharia.

Espero que isso ajude,

Bill

Não, porque

  • Você nunca faz funções matemáticas no código postal
  • Pode conter traços
  • foi possível iniciar com 0
  • valores nulos às vezes interpretado como zero em caso de tipos escalares como número inteiro (por exemplo, quando você exportar os dados de alguma forma)
  • Código postal, mesmo que seja um número, é uma designação de uma área, ou seja, este é um nome em vez de uma quantidade numérica de qualquer coisa

CEP é realmente um espaço de nomes codificados, se você pensar sobre isso. Tradicionalmente dígitos, mas também um hífen e maiúsculas:

"10022-SHOE"

http://www.saksfifthavenue.com/main/10022-shoe.jsp

Realisticamente, um monte de aplicativos de negócios não vai precisar de apoio a este caso extremo, mesmo se ele é válido.

Integer é bom, mas ele só funciona nos EUA, razão pela qual a maioria das pessoas não fazê-lo. Normalmente eu só usar um varchar (20) ou assim. Provavelmente um exagero para qualquer localidade.

Se você fosse usar um inteiro para US Zips, você iria querer multiplicar o papel principal por 10.000 e adicione a +4. A codificação no banco de dados não tem nada a ver com a validação de entrada. Você sempre pode exigir a entrada para ser válido ou não, mas o armazenamento é questão de quanto você acha que suas necessidades ou o USPS irá mudar. (dica:. suas necessidades irá mudança)

aprendeu recentemente que em ruby ??uma razão que você gostaria de evitar isso é porque existem alguns códigos postais que começam com zeros à esquerda, que, se armazenado como no inteiro-será automaticamente convertido em octal.

A partir os docs :

Você pode usar um prefixo especial para números gravação em decimal, hexadecimal, octal ou formatos binários. Para decimal números usar um prefixo de 0d, para números hexadecimais usar um prefixo de 0x, para números octais usar um prefixo de 0 ou 0o ...

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top