Existe um design de database de endereços comuns para todos os endereços do mundo?

Eu sou um programador e, para ser honesto, não conheço as estruturas de endereços de rua do mundo, como no meu país está estruturado 🙂 então qual é o melhor e mais comum projeto de database para armazenar endereços de ruas? Deve ser tão simples de usar, rápido para consultar e dynamic para armazenar todos os endereços de rua do mundo que está identificando apenas por um id
Muito obrigado

É possível representar endereços de vários países em um conjunto padrão de campos. A idéia básica de uma rota de access nomeada (via pública) na qual os edifícios nomeados ou numerados estão localizados é bastante padrão, exceto na China às vezes. Outros conceitos quase universais incluem: nomear o assentamento (cidade / vila / vila), que pode ser genericamente chamado de localidade; nomeando a região e atribuindo um código postal alfanumérico. Observe que os códigos postais, também conhecidos como códigos postais, 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 vários países em um formato padrão . Note que o formato UPU contém todos os endereços (até a precisão do campo disponível) para um país inteiro, portanto, é relacional. Se o armazenamento de endereços de clientes, onde apenas uma pequena fração de todos os endereços possíveis serão armazenados, é 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
  • CEP (ou código postal)
  • País

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

  • Construção
  • Sub-edifício
  • Número da premissa (número da casa)
  • Faixa Premissa
  • Passagem
  • Subtabela
  • Localidade Dupla Dependente
  • 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 as vírgulas sempre podem ser usadas como separadores de linha, o que significa que as informações ainda podem ser capturadas.

Geralmente, 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, eles não podem ser usados ​​localmente.

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

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

(Todo o tipo de dados de caracteres de comprimento variável)

AddressId Line1 Line2 Line3 City ZipOrPostcode StateProvinceCounty CountryId OtherAddressDetails 

insira a descrição da imagem aqui

Pergunte a si mesmo qual é o objective principal de armazenar esses dados? Você pretende enviar um e-mail para a pessoa no endereço? Acompanhe demografia, populações? Poder pedir aos chamadores o endereço correto como parte de alguma autenticação / verificação básica? Tudo acima? Nenhuma das acima?

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

Às vezes, o mais próximo que você pode chegar a um endereço de rua é a cidade.

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

Então eu peguei os dados do cliente. Alguns endereços escolares eram coisas como “Do outro lado do mercado, ao lado do barbeiro” ou “Perto do antigo ponto de ônibus”.

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

Para endereços internacionais, é extremamente difícil encontrar uma maneira de formatar a informação se ela estiver dividida em campos. Por exemplo, um endereço italiano usa:

      

Tal como

 Via Eroi della Repubblica 89861 Tropea VV Italy 

Isso é um pouco diferente da ordem dos endereços dos EUA – na segunda linha.

Veja também as perguntas do SO:

  • Quantos campos de endereço você usaria para um database no Reino Unido?
  • Você divide endereços em rua / cidade / estado / CEP?
  • Como você lida com sufixos de rua duplicados?
  • Melhores práticas para armazenar endereços postais em um database (RDBMS)?

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


Editar : ordem inversa da região e da cidade – por UPU

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 primeiro nível, código de telefone, sinal de carro, comprimento e regex de fecho eclair. Nomes de países e comentários infelizmente apenas em alemão …

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

Apenas fora do chapéu, posso pensar na seguinte estrutura:

  • País
  • Região (estado / província)
  • Localidade (Cidade / Município)
  • Sub-localidade (condado / outra subdivisão de uma localidade)
  • Rua

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

Uma maneira que eu sempre acho que pode ser realizada é pedir o CEP (ou Código Postal), que varia de país para país, mas é sólido dentro do país.

Desta forma, você pode estruturar seus dados em torno das informações fornecidas pelos escritórios postais em todo o mundo.

Depende de quão livre você está preparado para ir com os campos. Um campo de endereço de forma livre obviamente sempre fará, mas será de relativamente pouca ajuda para restringir a geografia.

O problema que você terá é que há muita variação no nível de 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 fazer isso muito inteligente.

Len Silverston, da Universal Data Model, fama recomenda uma hierarquia separada de GEOGRAPHIC BOUNDARIES e, dependendo da quantidade de livre-formação que você está disposto a aceitar, seja simples ou STREET ADDRESS LINE ou derivados por país.

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

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

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

ATUALIZAR:

Pensando bem, tudo pode ser feito, mas há um trade-off.

Uma abordagem é modelar o problema com as tabelas address_attribute e address, com uma relação 1: m entre elas, tudo pode ser modelado. A tabela address_attribute teria um pk, um nome, um valor e um fk que aponta de volta para o pk do seu pai de endereço. É quase como usar um mapa com nome, pares de valores.

O trade-off é ter que fazer um JOIN toda vez que você quiser um endereço. Você também tem que interrogar os nomes dos endereços_atributos para descobrir com o que você está lidando a 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 objects, você pode ter a class Address ocidental (street1 / street2 / city / state / zip) e outras para o Japão, China, quantas forem necessárias para delimitar o espaço de endereço. Então você teria uma tabela de endereços mestre e tabelas filhas para os outros tipos com uma relação de 1: 1 entre eles.

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

Seu design deve depender fortemente do seu propósito. Algumas pessoas postaram como estruturar dados. Então, se você simplesmente quer enviar um e-mail para alguém, ele vai funcionar. As coisas começam a complicar se você quiser usar esses dados para navegação. A navegação do carro exigirá estruturas adicionais para conter informações de tráfego (por exemplo, estradas de sentido único), enquanto a navegação de pedestres exigirá muitos dados adicionais. Aqui está um pequeno exemplo: na minha cidade, meu bairro fica perto do parque. Ao lado do parque é ex-aeródromo (na verdade, um dos mais antigos da Europa) se transformou em museu da aviação. Ao lado do museu da aviação é um parque empresarial. O número da rua para o museu é 39, enquanto os números do parque empresarial começam com 39A. Portanto, pode parecer que 39 e 39A estão próximos – mas leva cerca de um quilômetro para andar de um para outro (e ainda mais se for de carro).
Este é apenas um pequeno exemplo tirado da minha cidade, acho que você pode encontrar muitas exceções (especialmente em regiões rurais ou selvagens de todos os países).