Existe um benefício para o armazenamento de dados de endereços de rua distintamente em vez de apenas como uma string?

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

Pergunta

Atualmente nós armazenamos nossos dados de endereço assim: 

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

Mas eu estou correndo para o (comum do que eu posso dizer) problema de analisar os primeiros 5 partes de endereço quando se lida com importadores e endereços.

Estou pensando que tudo isso seria muito mais fácil se o endereço de rua eram apenas uma string (varchar no db).

Existem 2 argumentos que me foi dado por que deveríamos mantê-lo como é: 1. Searching é mais fácil quando você pode pesquisar contra apenas o nome da rua ou número etc, mas eu estou pensando que um script sql ao longo das linhas de Select X do endereço onde streetAddress LIKE "% ENTRADA %" ; Claro que não é tão rápido, mas ele iria trabalhar (e o conjunto de dados para que a pesquisa é apenas em clientes é incrivelmente menor do que o conjunto de todos os endereços que temos armazenados).

  1. Atualmente, temos um sistema que bandeiras apartamentos - se você achar que uma pessoa no endereço Um é um apartamento, nós sinalize-os, e ele irá procurar todas as outras pessoas naquele streetnumber / streetname e sinalizá-las, bem como (este é um às vezes necessidade importante de negócios)

Já armazená-los todos como cordas por causa das inumeráveis ??exceções em endereços.

Então eu pergunto, existem razões específicas para a necessidade / desejo para armazenar as peças de endereço rua separadamente?

Foi útil?

Solução

Eu escrevi um blog inteiro post sobre isso um tempo atrás. Há muito boas razões para armazenar cada pedaço de dados em um campo separado. Não menos importante para a validação dos dados de endereço.

É claro, depende do que você está na indústria e que a informação está sendo utilizado. Se os dados de endereço inválido não está custando sua empresa nada, então por todos os meios armazenar dados inválidos. Esteja ciente de que embora abaixo da estrada você pode querer usar esses dados para correspondência, relatórios demográficos etc. Se os dados forem inválidos, não é trivial para corrigi-lo após o fato.

Aqui está o meu blog:

http://www.endswithsaurus.com/2009 /07/lesson-in-address-storage.html

Além disso, em referência a pesquisa "Onde StreetAddress Like '% qualquer que seja%'". Isto é tudo muito bem se você estiver fazendo uma busca rápida para seu próprio benefício, mas quando você vem para tentar automatizar partes de seu sistema que dependem de dados de endereço ou mesmo tentar jogar duplicatas, fornecer aos usuários com auto-sugestão etc etc, o desempenho é degradado a um ponto que ele vai se tornar inutilizável o maior tabela de endereços.

Se endereços inválidos não são uma preocupação que vai custar à empresa o dinheiro real, então não é um problema - mas, em seguida, se você não estiver usando os endereços para qualquer coisa que é benéfico financeiramente (ou susceptíveis de estar em o futuro), então por que você armazenar essa informação em primeiro lugar?

@Snorfus Ah, você deve estar nas pradarias. Eu tinha esquecido incluindo postagem sobre as descrições de terra no meu blog, mas é algo que eu estou considerando para um post mais tarde.

subdivisões Jurídicos (DDL) são utilizados primariamente em Oil & Gas e de outras indústrias de recursos primários em Alberta, Saskatchewan e Manitoba (embora eles são encontrados em partes da aC também, eles não estão em tal uso predominante). todas elas têm o mesmo formato: Seção, Township, Gama, Meridian. Por exemplo:

SE 28-12-17-W5

Este é o canto sudeste da Seção 28, Township 12, Gama 17, West da 5ª Meridian.

Você poderia simplesmente usar um único campo e analisá-lo com expressões regulares ou quebrá-lo para fora em campos separados contendo a ruptura do LSD. Correndo expressões regulares no SQL Server pode ser uma dor quando se trata de desempenho. Minha opinião sobre isso é o mesmo que o de dados de endereço, em geral, isso porque cada pedaço de dados é uma peça única separado de dados que devem ser armazenados em campos separados. No entanto, dado que a grande maioria deste tipo de dados de endereço é não usado pelo público em geral, em vez de um endereço, eu poderia recomendar projetar algo que permitiria que esta informação seja separado (mas ligada a) os seus principais dados de endereço. Dado, porém, que a descrição da terra / LSD também é parte de cada endereço canadense, eu poderia ser tentado a armazená-lo em minha mesa endereço principal, dependendo do público-alvo do banco de dados.

Aqui está um post sobre o colapso do sistema de Recursos Alberta terreno:

http://www1.agric.gov. ab.ca/%24department/deptdocs.nsf/all/agdex10302

Uma coisa que você vai encontrar muitas vezes em Oil & Gas, pelo menos, (que é onde a maior parte da minha experiência vem) é que os trabalhadores referem-se frequentemente apenas as duas primeiras partes do LSD - ou seja, 28 de 12, ou 43 de 16. o restante do LSD está implícita a localização do endereço -. ou seja, Grand Prairie, Fox Creek, Wolf Lake etc

Outras dicas

Eu costumava pensar que era uma boa idéia, até que meus pedidos foram implantados e um fluxo constante de pedidos veio para mudanças. Na época, eu morava em Ontário, Canadá e eu pensei que eu sabia o que um endereço padrão parecia. Até que algum cliente tinha um endereço que combinou o P.O. Box e o endereço da rua em um. Em seguida, os clientes Alberta começaram a chegar com seus códigos estruturados mencionados em outra resposta. Em seguida, British Columbia Endereços onde não havia nenhuma rua ou street número, apenas um site e Compartimento e Rota Rural. C4, S16 RR7 Mountainville. E depois com fornecedores americanos, as regras de código postal saiu pela janela. E, em seguida, o cliente britânico ocasional apareceu no banco de dados e tudo o que você achava que sabia sobre endereços sai pela janela. Um nome prédio sem número de rua, dois nomes de rua, dois cidade nomes em um só endereço! 

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

Isso é um exemplo inventado, mas eles existem. Os britânicos conseguem sobreviver porque cada empresa local tem um up ao banco de dados de endereços nacional data e todos eles precisam é o nome ou o número de código postal e casa. O resto é preenchido a partir do banco de dados.

No caso de esse endereço, provavelmente há outra Crescent Waverly em Fervendo-under-Norton, razão pela qual o segundo nome de rua. E Seething-under-Norton era uma vila que por muito tempo se tornou incorporados a cidade de Banbury, para que ambos os nomes estão no endereço. Nos endereços britânicos muitas vezes você obterá municípios que não existem. Eles são considerados cidades postais em que eles só existem dentro do sistema postal. Geralmente, há uma base histórica para o nome. Lotes de endereços de Londres são assim com as pessoas escrevendo Londres uma vez, e Leyton ou South Ruislip ou Hillingdon outra vez. As letras todos ficam prontamente entregues.

Assim, a menos que uma característica do seu software é que ele impede as entradas de endereços estrangeiros no sistema, não faça isso!

A propósito, você mencionou a identificação de todas as pessoas na mesma rua pelo nome da rua. você tem verificado Denver Colorado onde há nomes de ruas que terminam e pegar novamente, uma milha mais longe. Uma vez eu me perdi em Littleton (Denver subúrbio) tentando encontrar um determinado endereço apenas para ser dito que eu precisava de um outro tal tal e rua que estava em outro lugar. Depois, há a prática britânica de utilizar dois ou mais nomes para cada estrada. Por exemplo, haverá uma estrada Homerton que é então chamado Marsh Hill e, em seguida, Homerton High Street e depois Urswick Road e, em seguida, Lower Clapton Estrada tudo no espaço de um ou dois quilômetros. Mais comumente, na aldeia de Wick haverá uma estrada Norton. Se você segui-lo, depois de uma ou duas milhas você vai notar que a sua está agora em Wick Road, entrar na aldeia de Norton.

Na minha opinião, há algum benefício para fazer isso, mas em todos os casos em que eu vi ele tentou, o custo ea complexidade de fazê-lo superam os benefícios insignificantes.

Não é o menor dos seus problemas, vai ser a formação / forçar os usuários a respeitar todos os campos separados que lhes dão para entrar todas as diferentes partes que compõem e endereço em um formato consistente - a maioria das pessoas simplesmente não pensar um endereço a ser composta por até 5 partes diferentes, e, provavelmente, basta digitar coisas como eles costumam fazer.

Então, se não para as pessoas realmente tentando usar o sistema era, seu provavelmente uma boa idéia.

Na Europa, o endereço é geralmente um nome de mais um "número" (onde número pode ser algo como "3a"). Eu vi bancos de dados que eles armazenam separadamente por uma única razão: Você pode procurar os nomes das ruas em um banco de dados oficial para verificar a eles (por exemplo, para proteger contra erros de digitação). Portanto, para este caso de uso, não faz sentido manter a peças verificáveis ??e não-verificável em colunas diferentes.

Eu duvido que você possa encontrar uma razão para dividi-la ainda mais, exceto por um medo difuso que você pode perder informações.

É um benefício se você está seguindo uma abordagem orientada objetou para modelar todo o seu domínio. Sua pergunta me lembra este título do blog março não é um número como uma resposta. Algo análogo podia ser palavra sobre ruas e endereços ( "A rua não é uma string"). SnOrfus aponta um problema válido em seu comentário.

Enquanto o seu pode ser vantagens para armazenar cada componente de um endereço de forma independente, você terá que pesar o custo contra suas necessidades e requisitos de negócios. Se você não está fazendo qualquer coisa relacionada a discussão ou o envio, pode ser um exagero e aspectos complicar de sua arquitetura significativamente. Além disso, qualquer outra pessoa que funciona em seu código pode não entender o que está acontecendo e fazer apresentar problemas significativos sem perceber, corrompendo assim o banco de dados.

Por exemplo, nos Estados Unidos, o seguinte é a "linha de entrega" de uma rua: PO Box 12345.

Neste caso, "PO Box" é na verdade o nome da rua, enquanto 12345 é o número principal. Normal "formatação" e sabedoria convencional sugere que um endereço deve ter o número principal listado em primeiro lugar, como em "123 Main Street".

Se você está formatando o endereço de volta juntos de forma padrão, você terá que se lembrar de como o endereço parecia inicialmente.

Este é o lugar onde verificação de endereço e padronização entrar. Pelo menos dentro dos Estados Unidos e algumas outras nações nações modernas, incluindo Grã-Bretanha, você tem a vantagem de ser capaz de enviar o endereço para um endereço de serviço de verificação on-line que pode limpo, padronizar e verificar o seu endereço. Muitas vezes, esses serviços vão devolver o endereço como ele deve aparecer na peça mail, bem como as partes componentes do endereço. Se você tem uma necessidade de negócios para os componentes, então você pode armazená-los de forma independente. Caso contrário, outra chamada para o serviço web verificação de endereço deve produzir os componentes novamente no momento desejado.

No interesse da divulgação cheia, eu sou o fundador da SmartyStreets. Oferecemos serviços verificação de endereço com sede nos EUA que incluem CASS-Certificado validação de seus endereços. Você é mais que bem-vindo a contactar-me pessoalmente com todas as perguntas que você tem.

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