O que é uma maneira universal de armazenar um endereço / local geográfico em um banco de dados? [fechadas]

Qual é o formato correto de um endereço / local geográfico adequado para qualquer endereço na Terra? No momento eu tenho:

• país
• cidade
• rua
• número
• dados de texto (para simplificar)
• fecho eclair
• lat / lng

Mas acredito que posso melhorá-lo: pode haver um estado / região de um país ou algo parecido com área. Ou nenhuma área / região / estado, digamos, em Cingapura ou Hong Kong.

Pode não haver rua, mas estrada ou avenida ou outra coisa. Um número de um edifício pode ser composto. Pode haver um piso. Um número de quarto. Etc ....

O Google desenvolveu uma biblioteca que ajuda a validar endereços postais para todos os países do mundo, que você pode usar para criar um esquema para armazenar esses dados.

Procure os campos obrigatórios mais comuns nos endereços da sua base de clientes-alvo para começar e, à medida que você identifica outros países com requisitos diferentes, pode continuar ajustando seu esquema.

A maneira universal de armazenar um endereço / localização geográfica em um banco de dados é esta:

[Address] nvarchar(max) not null

Isso requer a menor quantidade de código de programação (e, portanto, reduz os custos de manutenção) e é totalmente compatível com qualquer endereço. No entanto, há três grandes problemas:

• A falta de validação de dados significa que o campo pode ser usado para outros fins que não o armazenamento do endereço. Um dos propósitos é um ataque do DOS destinado a preencher o espaço do seu banco de dados digitando 2 GB de dados no campo de endereço.

• Os dados armazenados dessa maneira tornam impossível processá-los para fins de business intelligence e mineração de dados. Por exemplo, quantos usuários são da Índia? Não há uma maneira fácil de saber, pois esses endereços não serão normalizados.

• Os usuários podem digitar incorretamente um endereço incompleto ou claramente errado.

Para atenuar o primeiro problema, limite o campo ao que você considera um limite razoável. Pessoalmente, eu começaria com 1.000 caracteres e depois o reduziria com base no tamanho dos endereços inseridos pelos primeiros usuários quando você obtiver um conjunto de dados grande o suficiente.

Para atenuar os outros dois problemas, você pode usar uma API de terceiros que analisa endereços e apresenta os dados que contêm o país, cidade, código postal etc. Se possível, a API deve poder exibir o endereço em um mapa de volta ao usuário para reduzir o risco de o usuário inserir um endereço incompleto ou errado: a maioria dos usuários sabe onde mora, e ver uma posição diferente em um mapa daria a ele imediatamente uma pista de que eles deveriam verificar suas informações.

Observe que, independentemente da API que você usar, não será perfeita. Ele encontrará a maioria dos endereços, mas não todos. Isso significa que, se a API diz que o endereço não existe, mas o usuário insiste que sim, você deve, a priori, confiar no usuário, mesmo que ele esteja errado.

Isso também significa que você ainda deve armazenar a entrada do usuário original, lado a lado com o resultado da API. Isso significa que o esquema se torna:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

Não existe um.

Cada país tem diferentes formatos de endereço. Se você tiver sorte, e eles tiverem um formato!

Obviamente, latitude / longitude lhe dará um ponto no mundo, mas não é realmente útil para identificar casas individuais. Basta considerar um bloco de torre, por exemplo.

Sua melhor aposta é verificar o serviço postal de cada país em busca de um formato oficial. Isso pode ser ótimo para o banco de dados back-end. Mas você provavelmente precisará simplificá-lo para os usuários finais, pois ele conterá muito mais campos do que a maioria das pessoas está acostumada.

O Reino Unido, por exemplo, inclui coisas como 'localidade dependente dupla', mas ninguém saberia o que isso significava se você perguntasse a eles.

O único formato universal é ter um único campo de texto que pode ter várias linhas de texto. Isso permitirá qualquer endereço possível na Terra.

Tenho desenvolvido soluções de software para serem usadas em muitos países. Abordamos esse problema começando primeiro pela entidade maior, ou seja, o país possui campos até o menos comum ou o menor. Funciona bem em todos os países com os quais experimentamos até agora. Também temos um sistema inteligente de prevenção de duplicatas e uma fusão para aqueles que de alguma forma entram no sistema, já que os usuários são muito "criativos". Na seção admin, temos uma ordem de campo de endereço por configuração de país. ou seja, o Japão tem o código postal primeiro onde o Reino Unido / EUA é o último.

Em geral, usamos:

• País
• Post / CEP
• Estado / Província / Província / Condado
• Cidade / Vila / Vila
• Rua / Estrada / Bloco
• Nome / Número do Edifício
• Informações específicas / personalizadas

Uma vez inserida e salva, uma versão conjugada pode ser exibida, deixando de fora os campos desnecessários.

Como eu disse, isso funciona para todos os países em que temos softwares e é o resultado do desenvolvimento desde 1989.

Espero que isso ajude de alguma forma ou pelo menos forneça outra visão.

Como já foi dito, o mais universal (mas impraticável para validar e talvez menos útil) é um único campo unicode grande.

Você pode separar o país do restante do endereço e armazená-lo como o código ISO do país. Normalizaria o país e ofereceria alguma utilidade na validação do restante do endereço.

Você também pode separar o código postal, também conhecido como CEP, do resto do endereço. Isso também teria alguma utilidade na validação do restante do endereço e poderia ser útil (embora impreciso) na localização geográfica. Por exemplo: no Canadá, você pode identificar exclusivamente qualquer endereço especificando apenas código postal e número da rua (também conhecido como número da casa); isso pode não ser verdade em todos os países.

A dedicação de campos a estados / províncias ou cidades começa a ficar mais problemática devido às variações na maneira como cada país formula um endereço. Configurei tabelas de endereços com esses campos porque o público-alvo inicial é focado na América do Norte, sabendo que um público internacional representaria um problema para se encaixar. Na maioria dos casos, eles podem ser "insinuados", mas é um compromisso constrangedor e potencialmente propenso a falhas - definitivamente não é universal.

Ao contrário da resposta de Mitchdav, eu desaconselharia o uso da biblioteca do Google. Procurei no repositório vários locais internacionais com esquemas de endereçamento não ortodoxos na esperança de encontrar dados de teste de unidade, mas, preocupantemente, encontrei zero acertos em todo o repositório.

Acho que sua melhor aposta é tratar um endereço como texto de várias linhas de forma livre. É uma pena que você talvez não consiga validar todos os endereços, mas alguns formatos de endereçamento são realmente estranhos e possivelmente imprevistos e, no final, a responsabilidade de preencher o endereço correto depende do usuário e, na maioria dos aplicativos, o usuário tem consequências negativas ao preencher um endereço. endereço inválido.

Talvez você possa usar um validador para fornecer um aviso , mas nada além disso. Mas não rejeite endereços que não validam, pois caso contrário você poderá perder alguns clientes. O que leva à questão de como comunicar o aviso ao usuário de forma que ele comunique que, se o usuário mora em uma área com um formato de endereço estranho, é seguro ignorar o aviso ...

Como você diz em qualquer endereço na Terra , só há muito tempo ou ...

https://what3words.com

Com três palavras, é um algoritmo (que não é um banco de dados que pode ser incorporado a qualquer coisa) que pode definir um trecho de 3x3 metros em qualquer lugar da Terra.

Tonga e alguns outros estados o adotaram como seu sistema de código postal, embora não o substitua como uma sobreposição, é muito legal e muito bem construído e pensado.