Modelagem de Localizações Geográficas em um Banco de dados Relacional

Question

Eu sou a concepção de um sistema de gestão de contactos e deparei com uma questão interessante sobre a modelagem de localizações geográficas de uma forma consistente.Eu gostaria de ser capaz de gravar os locais associados a uma determinada pessoa (endereço para correspondência(es) para o trabalho, escola, casa, etc.) É o meu pensamento para criar uma tabela de localidades, tais como o seguinte:

Localidades (ID, LocationName, ParentID) onde autónomas locais (como países, por exemplo,EUA) são os pais de si.Dessa forma eu posso ter um arbitrariamente profundidade de aninhamento de "unidades políticas" (PAÍS > ESTADO > CIDADE ou PAÍS > ESTADO > CIDADE > UNIVERSIDADE).Alguns consulta envolverá necessariamente a recursividade.

Eu gostaria de quaisquer outras recomendações ou talvez aconselhamento sobre os previsíveis problemas que eu sou provavelmente encontrar com um tal regime.

Answer 1

Você pode querer ter um olhar para Freebase.com como um site que tinha alguma discussão aberta sobre o que é um "local" significa e o que isso significa quando um local está incluído no outro.Estes tipos de perguntas podem gerar muita discussão.

Por exemplo, há uma óbvia "geográfica do assentamento", mas há menos óbvio, lógico elementos aninhados.Por exemplo, no rigoroso sentido geográfico, a Cidade do Vaticano está aninhada dentro da Itália.Mas não é aninhado politicamente.Da mesma forma, se o usuário estiver localizado em um centro de pesquisa que pertence a uma universidade, mas não é localizado na Universidade da propriedade, você modelo de relacionamento ou não?

Answer 2

Soa como uma boa abordagem para mim.A única coisa que eu não estou claro em quando ler post é que "os pais " de si" entende - se isto é para indicar que o local não tem um pai, você é melhor fora de usar nulo do que a IDENTIFICAÇÃO de si mesmo.

Answer 3

Eu acho que você pode ser overthinking isso.Há uma razão para a maioria dos sistemas de armazenamento de endereços e, talvez, uma tabela de países.Aqui estão algumas coisas a olhar para fora para:

1. Gostaria de um endereço no Bronx incluir o município como um nível na hierarquia?Gostaria de um endereço em uma área não-incorporada eliminar a "cidade" nível de hierarquia?Como modelo de um endereço dentro de uma universidade vs um endereço que não é dentro de um?Você vai acabar com uma hierarquia desalinhada, o que irá forçar você para percorrer a árvore a cada vez que você precisar exibir um endereço em seu aplicativo.Se você tiver um "livro de endereços" página a perda de desempenho pode ser significativo.

2. Eu não tenho certeza de que você ainda tem apenas uma hierarquia.Universidade de Brown tem instalações em Providence, RI e Bristol, RI.A única solução seria ter uma dupla hierarquia com dois campi que cada pertencem aos seus respectivos cidades em uma hierarquia, mas que ambos pertencem à Universidade de Brown por outro hierarquia.(A universidade é, fundamentalmente, ao contrário de um político da região.Você realmente não deve misturá-los.)

3. O que sobre códigos postais?Alguns códigos postais abranger várias cidades, outras vezes de uma cidade é dividida em vários códigos postais.E (raramente), alguns códigos postais até mesmo atravessar as fronteiras do estado.(De acordo com a Wikipedia, pelo menos...)

4. Como você irá inserir os dados?Construção de banco de dados, análise de convencionou-formatado endereços pode ser difícil se você levar em conta a vaidade endereços, nomes alternativos para certas ruas, diferentes formatos internacionais, etc.E eu acho que entrar em cada endereço hierarquicamente seria uma PITA.

5. Parece que você está tentando modelar o mundo inteiro na sua aplicação.Você realmente quer ou precisa manter uma tabela que pode concebível conter cada cidade, província, estado, código postal, país e no mundo?(Ou pelo menos a cada um onde você conhece alguém?) A única coisa que eu posso pensar que esse esquema de comprar você é a proximidade, mas se é isso que você quer que eu tinha acabado de armazenar o estado e país separadamente (e talvez o cep) e adicionar dados de latitude e longitude do Google.

Desculpe para o extremo pessimismo, mas eu tenho ido por esse caminho sozinho.É logicamente bonito e elegante, mas ele não funciona tão bem na prática.

Answer 4

Aqui está uma sugestão para um belo esquema flexível.Um aviso imediato:ele poderia ser muito flexível e complexo para o que você realmente precisa

Localização (LocationID, LocationName) -- Bloco básico de construção

LocationGroup (LocationGroupID, LocationGroupName, ParentLocationGroupID) - Isso pode eficaz encapsular várias hierarquias.Você tem um nó de raiz e, em seguida, você pode criar vários ramos independentes.E. g.você pode dividir por estado primeiro e, em seguida, criar vários sub-hierarquias e.g.CEP/cidade/xxxx

LocationGroupLocation (LocationID, LocationGroupID) -- Veja como ligação Local com uma ou mais hierarquias.E. g.você pode vincular sua casa para um ZIP, bem como uma Cidade...O que você precisa para implementar uma restrição de que você não deve ser capaz de vincular a um local com as duas hierarquias, onde um deles é o pai dos outros (como a relação já está implícito).

Answer 5

Eu gostaria de pensar cuidadosamente sobre isso, pois não pode ser um recurso necessário.Por que não usar apenas um campo de texto e permitir que os usuários digite um endereço?

Lembre-se o Princípio KISS (Keep It Simple, Stupid).

Answer 6

Eu concordo com os outros posts que você precisa ter muito cuidado aqui sobre suas necessidades.Local pode se tornar um problema complicado e é por isso que sistemas GIS são tão complicted.

Se você tem certeza de que você só precisa de uma hierarquia básica estrutura, tenho as seguintes sugestões:

• Eu apoio o comentário anterior de que a raiz de itens de nível não deve ter-se como o pai.Raiz itens de nível deve ter um valor nulo para o pai.Tenha sempre o cuidado de colocar os dados em um campo que não tem significado (por exemplo,"especial" valor para representar dados não).Esta prática, raramente é necessariamente e caminho em demasia no devleoper comunidade.
• Considere XPath / XML.Isso é Algo a considerar para incomodar a gravação da hierarquia da estrutura, e para o processamento / análise de dados de recuperação.Se você estiver usando MSSQL Server, as expressões XPath em instruções select são perfeitos para tarefas tais como retornar a localização completa/hierarquia caminho de um registro de como o código é simples e os resultados são rápidos.

Answer 7

Para localizações Geográficas que você pode desejar para resolver um endereço a uma Latitude, Longitude matriz (talvez usando o Google maps, etc.) para calcular proximidades etc..Para Geopolítico de nidificação ...Eu iria com o BEIJO de resposta.

Se você realmente deseja modelá-lo, talvez você precise de tipos para ser mais genérico ...País -> Estado -> Distrito> Concelho -> Localidade -> Cidade -> Subúrbio -> Rua ou Caixa POSTAL -Número > - > - > Apartamento etc.-> Instituição (Universidade ou Empregador) -> Divisão -> Subdivisão-1 -> subdivisão-n ...Tem certeza de que não pode BEIJAR?

Answer 8

Eu sou a modelagem de um aplicativos para usuários globais e eu tenho o mesmo problemas, mas eu acho que esta abordagem poderia já estar em uso em muitas empresas.Mas porque é que este problema não tem uma solução universal?Ou, tem este problema de uma melhor solução, que pode ser o ponto de partida ou qualquer pessoa no mundo precisa pensar em uma solução para isso desde o começo?NELE, nós estamos fazendo as mesmas coisas todas as vezes e em muitos lugares, infelizmente.Por exemplo, que não têm feito mais de um usuário, do cliente ou do produto de banco de dados?E o pior, todas as empresas do mundo tem feito isso.Eu acho que poderia ter soluções universais para problemas universais.