Existe design de banco de dados de endereços comuns para todos os endereços do mundo?


122

Sou programador e, para ser sincero, não conheço as estruturas de endereços do mundo, como está estruturado no meu país :) então, qual é o melhor e mais comum projeto de banco de dados para armazenar endereços? Deve ser tão simples de usar, rápido para consultar e dinâmico para armazenar todos os endereços do mundo que estão identificando apenas por um id.
Muito obrigado



Você perguntou sobre endereços, mas todas as respostas são sobre endereços postais ( qual é a diferença? ). Talvez o título deva ser alterado?
Wrygiel # 19/16

Respostas:


123

É possível representar endereços de vários países diferentes em um conjunto padrão de campos. A idéia básica de uma rota de acesso nomeada (via) na qual os prédios nomeados ou numerados estão localizados é bastante padrão, exceto às vezes na China. Outros conceitos quase universais incluem: nomear o assentamento (cidade / vila / vila), que pode ser referido genericamente como localidade; nomear a região e atribuir um código alfanumérico. Observe que os códigos postais, também conhecidos como CEPs, são puramente numéricos apenas em alguns países. Você precisará de muitos campos se realmente quiser ser genérico.

A União Postal Universal da UPU fornece dados de endereço para muitos países em um formato padrão . Observe que o formato UPU contém todos os endereços (até a precisão de campo disponível) de um país inteiro; portanto, é relacional. Se estiver armazenando endereços de clientes, onde apenas uma pequena fração de todos os endereços possíveis será armazenada, é melhor usar uma única tabela (ou formato simples) contendo todos os campos e um endereço por linha.

Um formato razoável para armazenar endereços seria o seguinte:

  • Linhas de endereço 1-4
  • Localidade
  • Região
  • Código Postal (ou CEP)
  • País

As linhas de endereço 1 a 4 podem conter componentes como:

  • Construção
  • Sub-construção
  • Número da premissa (número da casa)
  • Faixa de premissa
  • Passagem
  • Sub-via pública
  • Localidade dependente dupla
  • Sub-localidade

Freqüentemente, apenas três linhas de endereço são usadas, mas isso geralmente é insuficiente. É claro que é possível exigir mais linhas para representar todos os endereços no formato oficial, mas vírgulas sempre podem ser usadas como separadores de linhas, o que significa que as informações ainda podem ser capturadas.

Normalmente, a análise dos dados seria realizada por localidade, região, código postal e país e esses elementos são bastante fáceis para os usuários entenderem ao inserir dados. É por isso que esses elementos devem ser armazenados como campos separados. No entanto, não force os usuários a fornecer código postal ou região, pois eles não podem ser usados ​​localmente.

A localidade pode não ser clara, principalmente a distinção entre localidade de mapa e localidade postal. A localidade postal é aquela considerada por uma autoridade postal que às vezes pode ser uma cidade grande nas proximidades. No entanto, o código postal geralmente resolverá quaisquer problemas ou discrepâncias no local, para permitir a entrega correta, mesmo que a pós-localidade oficial não seja usada.


1
Você pode fornecer um URL para a UPU? (Sim, eu sei que eu poderia encontrá-lo -, mas as melhores respostas não fazem as pessoas fazer a pesquisa.)
Jonathan Leffler

Tente upu.int/post_code/en/… e escolha o país apropriado no menu suspenso
barrowc

Adicionado URL para UPU Post * Code product
Edward Ross

17
Além disso, alguns países (República da Irlanda, por exemplo) não usam CEP. Se eu tivesse um centavo pelo número de vezes que tinha que inserir na (não aplicável) como um código postal, porque é um técnico de campo obrigatório. . . Eu teria cinco ou seis cento até agora :)
Binary Worrier

se a UPU possui listas para download, atualmente, eles fizeram um bom trabalho em mantê-las muito bem ocultas.
Jahmic

47

Dê uma olhada no Database Answers . Especificamente, isso abrange muitos casos:

(Todos os tipos de dados de caracteres de tamanho variável)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

insira a descrição da imagem aqui


Não diminuí a votação, mas acho que a única maneira de isso funcionar seria se todos os campos, exceto AddressId e Line1, fossem opcionais. Nesse caso, não é muito útil.

11
Os tipos de dados são importantes - nem todos os países têm códigos postais inteiros! Um colega de trabalho descobriu isso rapidamente com um cliente no Canadá.
Eric

1
@Eric: Além de campos ID todos esses campos são tipos de dados de caracteres
Mitch Wheat

2
Para o ID do país, você deve usar o código de país ISO 3166 de duas letras (ou três letras). O esquema proposto permite armazenar um endereço analisado; ele não informa sobre como formatá-lo. (Ah, e o Reino Unido tem códigos alfanuméricos - IP31 3GH, SE1W 9PQ etc.) Acho que o segundo grupo é sempre NAA; o primeiro grupo começa com A e contém pelo menos um N (A = alfa, N = dígito), mas nada me surpreenderia).
Jonathan Leffler

@ Neil: Exatamente. Há tanta variação por país que você não pode usar uma única tabela e espera que o banco de dados a valide.
Dave Sherohman 02/06/2009

26

Pergunte a si mesmo qual é o principal objetivo de armazenar esses dados? Você pretende realmente enviar e-mail para a pessoa no endereço? Acompanhar dados demográficos, populações? Ser capaz de pedir aos chamadores o endereço correto como parte de uma autenticação / verificação básica? Tudo acima? Nenhuma das acima?

Dependendo da sua necessidade real, você determinará: a) isso realmente não importa e pode optar por uma abordagem de texto livre; b) campos estruturados / específicos para todos os países; ou c) arquitetura específica do país.


Faz sentido. Estou procurando uma boa solução para esse problema, mas existem muitos diferentes. Como você disse: provavelmente é melhor escolher entre os requisitos reais.
displayname 29/02

12

Às vezes, o mais próximo possível de um endereço é a cidade.

Certa vez, tive um projeto para colocar todas as escolas secundárias na Índia no Google Maps. Escrevi um programa interessante usando a API do Google e achei que seria bem fácil.

Então eu peguei os dados do cliente. Alguns endereços de escolas eram do tipo "Do outro lado do mercado, próximo ao barbeiro" ou "Perto do ponto de ônibus antigo".

Isso tornou minha tarefa muito mais difícil, pois, infelizmente, a API do Google não suporta esse formato.


2
Os endereços asiáticos também são notórios por isso. "73rd Block West Ninjang St, Building 2, Take Second Elevator Upper, Complexo de escritórios ao lado da praça de alimentação, 468th Industrial District, Shanghai 456789" ...
ruhnet 18-18 de

9

Para endereços internacionais, é incrivelmente difícil encontrar uma maneira de formatar as informações se elas forem divididas em campos. Por exemplo, um endereço italiano usa:

<street address>
<zip> <town> <region>
<country>

Tal como

Via Eroi della Repubblica
89861 Tropea VV
Italy

Isso é bem diferente do pedido de endereços nos EUA - na segunda linha.

Veja também as perguntas do SO:

Verifique também a tag ' código postal '.


Editar : ordem inversa de região e cidade - por UPU


5

Talvez isso seja útil: https://gist.github.com/259744 Para um projeto, coletei uma tabela de informações sobre todos os países do mundo, incluindo códigos ISO, domínio de nível superior, código de telefone, sinal de carro, comprimento e regex de fecho eclair. Infelizmente, nomes e comentários de países apenas em alemão ...


2

Depende de como você está preparado para seguir com os campos. Um campo de endereço de forma livre obviamente sempre funcionará, mas será de pouca ajuda para diminuir a geografia.

O problema que você terá é que há muita variação no nível da hierarquia geográfica entre os países. Heck, alguns países nem sequer têm 'endereços' em todos os lugares.

Eu recomendo que você não tente torná-lo muito inteligente.


2

Diferentemente de outras respostas aqui, acredito que é possível ter um banco de dados de endereços estruturado.

Logo de cara, posso pensar na seguinte estrutura:

  • País
  • Região (Estado / Província)
  • Localidade (cidade / município)
  • Sub-localidade (município / outra subdivisão de uma localidade)
  • Rua

Mas como consultá-lo rápido o suficiente?

Uma maneira que sempre penso que isso pode ser feito é solicitar o CEP (ou CEP) que varia de país para país, mas é sólido dentro do país.

Dessa forma, você pode estruturar seus dados com base nas informações fornecidas pelos correios em todo o mundo.


2

Len Silverston, da fama do Universal Data Model, recomenda uma hierarquia separada GEOGRAPHIC BOUNDARIESe dependendo da quantidade de forma livre que você está disposto a aceitar STREET ADDRESS LINEderivadas simples ou derivadas por país.


1
É verdade, e os modelos criados por Silverston são muito bons e cobrem muito terreno, mas ainda não acho que essa complexidade seja aplicável à Web (neste momento), especialmente da perspectiva do usuário final. No final, a usualidade (quase) sempre vence.
Alix Axel

2

Não, absolutamente não. Se você comparar a maneira como os endereços dos EUA e do Japão funcionam, verá que isso não é possível.

ATUALIZAR:

Pensando bem, tudo pode ser feito, mas há uma troca.

Uma abordagem é modelar o problema com as tabelas de endereço e endereço_atributo, com um relacionamento de 1: m entre elas, qualquer coisa pode ser modelada. A tabela address_attribute teria um pk, um nome, um valor e um fk que apontam novamente para o pk do pai do endereço. É quase como usar um mapa com nome, pares de valores.

A compensação é ter que fazer um JOIN toda vez que você quiser um endereço. Você também precisa interrogar os nomes dos atributos de endereço para descobrir com o que está lidando cada vez.

Outra abordagem seria fazer uma pesquisa mais abrangente sobre como os endereços são modelados em todo o mundo. Em um mundo orientado a objetos, você pode ter a classe Address ocidental (street1 / street2 / city / state / zip) e outras no Japão, China, quantas forem necessárias para agrupar o espaço de endereço. Em seguida, você teria uma tabela de endereços mestre e tabelas filho para os outros tipos com um relacionamento 1: 1 entre elas.

Como a Amazon ou o eBay fazem isso? Eles enviam internacionalmente. Eles possuem recursos de interface do usuário específicos da localidade? Eu só usei a localidade dos EUA.


1
e se eu precisar da maioria dos endereços?
Arsen Mkrtchyan

Desculpe, não estou te seguindo aqui.
Duffymo 30/05/09

2

Não, não existe um esquema de endereçamento padrão. Geralmente varia de país para país. Até a União Postal Universal disse sobre o endereço do mundo, um endereço para todos que não existe. A melhor solução para isso é usar os padrões de código de país com 2/3 letras conhecidos como ISO 3166 e tratar todo o resto pelos padrões do país.

No entanto, se você realmente está desesperado para usar ferramentas facilmente acessíveis para seu projeto, experimente a API do Google Place .


Gosto muito da ideia de ver como a API do Google Place lida com as coisas!
Andrew Steitz

1

Seu design deve depender fortemente do seu objetivo. Algumas pessoas publicaram como estruturar dados. Portanto, se você simplesmente deseja enviar um email para alguém, será necessário. As coisas começam a complicar se você deseja usar esses dados para navegação. A navegação de carro exigirá estruturas adicionais para conter informações de tráfego (por exemplo, estradas de mão única), enquanto a navegação a pé exigirá muitos dados adicionais. Aqui está um pequeno exemplo: na minha cidade, meu bairro fica perto do parque. Ao lado do parque está o antigo aeródromo (de fato, um dos mais antigos da Europa) transformado em museu de aviação. Ao lado do museu da aviação é um parque empresarial. O número da rua do museu é 39, enquanto o número do parque comercial começa com 39A. Portanto, pode parecer que 39 e 39A estão próximos - mas leva cerca de um quilômetro para caminhar de um para outro (e ainda mais se você estiver indo de carro).
Este é apenas um pequeno exemplo da minha cidade, acho que você provavelmente encontrará muitas exceções (especialmente em áreas rurais ou selvagens de todos os países).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.