Temos uma equipe que projeta as tabelas e relações para desenvolvedores de software. Em nossa organização, eles são bastante rigorosos quanto à aplicação da normalização 3NF - o que, para ser honesto, concordo, dado o tamanho de nossa organização e como as necessidades de nossos clientes mudam com o tempo. Há apenas uma área que não tenho certeza sobre as razões por trás de sua decisão de design: endereços.
Embora isso se concentre principalmente em endereços nos Estados Unidos, acho que isso pode se aplicar a qualquer país que faça isso. Cada parte de um endereço obtém sua própria coluna na tabela de endereços. Por exemplo, pegue este endereço retorcido nos EUA:
Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
Ele seria dividido no banco de dados assim:
- Número da rua: 485
- Fracção de rua: 1/2
- Rua pré-direcional: N (Norte)
- Nome da rua: Smith
- Tipo de rua: ST (Rua)
- Rua pós-direcional: SW (Sudoeste)
- Cidade: Chicago
- Estado: IL (Illinois)
- CEP: 11111
- CEP4: 2222
- País (presume-se que seja EUA)
- Atenção: Jane Doe
- Caixa Postal: NULO
- Tipo de habitação: APT (Apartamento)
- Número da residência: 300B
E haveria algumas outras colunas relacionadas a rotas rurais e rotas contratadas. Além disso, nosso aplicativo específico provavelmente terá alguns endereços internacionais. Os modeladores de dados disseram que adicionariam colunas específicas para endereços internacionais, que seriam os campos normais da linha 1, linha 2.
No começo eu pensei que isso era MUITO exagerado. A pesquisa on-line refere-se repetidamente ao uso da linha de endereço 1, 2, 3 e possivelmente 4 e, em seguida, dividindo cidade, região e código postal. Temos um caso de uso para nosso novo aplicativo em que essa granularidade é benéfica. Temos que validar se o usuário não está criando um negócio duplicado, e verificar o endereço é uma das validações. Podemos fazê - lo funcionar com as linhas de endereço 1 e 2, mas seria mais difícil.
Quanto ao nosso aplicativo específico, precisamos armazenar vários tipos de endereços para empresas e pessoas (físico, postal, envio etc.). Podemos precisar gerar cartas de formulário imprimíveis, mas esse requisito não foi discutido até agora .
Algumas outras coisas que os aplicativos em nossa organização precisam suportar:
- Auditoria (com tabelas de histórico completas)
- Imprimindo etiquetas de endereçamento
- Gerando formulários impressos
- Relatórios (para governos nacionais e regionais)
Embora nosso aplicativo possa não estar fazendo tudo o que todos os outros aplicativos estão fazendo, dividir endereços em vários componentes é um padrão corporativo onde trabalho. Independentemente de nosso aplicativo se beneficiar disso, somos forçados a fazer isso.
Pergunta semi-relacionada do StackOverflow: onde está um bom analisador de endereços que foi fechado, mas ilustra como os endereços de análise podem ser difíceis.
Para que eu entenda melhor a decisão de design deles e venda a ideia ao nosso cliente...
Que problemas são resolvidos dividindo o endereço em colunas individuais?
Pontos de bônus para quem implementou um sistema como esse, porque teve problemas.
Passei 7 anos desenvolvendo software para uma editora e um dos problemas mais difíceis que já enfrentamos foi a análise de endereços nas listas de assinaturas. É útil dividir os endereços em campos distintos, mas você nunca, NUNCA pode projetar para cada aberração patológica possível de formatos de endereço e componentes que o cérebro humano possa conceber.
Cada localidade pode ter suas peculiaridades, e isso apenas nos EUA. Jogue em outros países e as coisas ficam incontroláveis muito rapidamente para qualquer abordagem que queira analisar todos os endereços. Apenas dois exemplos:
Na Espanha, o número da rua sempre vem depois do nome da rua e uma vírgula, e muitos endereços contêm um número de andar ordinal, como 1° ou 3ª, junto com abreviaturas para "esquerda" ("Izda" significando porta esquerda após você sobe as escadas), "certo" ("Dcha") ou outras possibilidades. Agora multiplique essa estranheza pelo número de diferentes países e áreas com diferentes costumes históricos para endereços... (Japão? Inglaterra rural? Coréia? China?)
Em Portland, OR, existem eixos NS e EW que dividem a cidade em quadrantes NW, NE, SW e SE (bem como um "quadrante" N, mas estou divagando). As ruas NS são numeradas de forma incremental a leste e oeste a partir deste eixo, e os endereços nas ruas EW são ditados pelo número da rua NS sendo o "quarteirão cem" do número (ou seja, uma casa em uma rua EW entre as avenidas 11 e 12 teria um número como 1123). Material bastante padrão para endereços nos EUA.
De vez em quando você encontra um endereço de Portland como 0205 SW Nebraska St. Um zero à esquerda? WTF? Lá vai minha
integercoluna para "número" da casa.Quando a grade foi montada, o eixo NS foi definido pelo rio Willamette. Tudo a leste do rio era NE ou SE, e a oeste do rio NW ou SW. À medida que a cidade crescia para o sul, eles se depararam com o fato inconveniente de que o rio serpenteia para o leste, projetando o eixo sul, você tem essa área problemática que fica no lado "oeste" do rio, mas a leste do eixo. A solução foi adicionar um zero à esquerda, na verdade um sinal de menos , com os números incrementando em direção ao leste a partir da linha do eixo.
Se eu fosse você, perderia a esperança de projetar o sistema definitivo. Você não pode cobrir todas as possibilidades, e novas serão criadas à medida que a humanidade avança para terras anteriormente subdesenvolvidas.
Para endereços nos EUA, dê uma olhada no que o USPS já fez na padronização de endereços e lembre-se de tornar a
house_numbercoluna umvarchar. Enquanto você está nisso, descubra como você vai analisar 1634 EN Fort Lane Ave .Para o resto do mundo, provavelmente tentaria abstrair campos adicionais para cobrir 80-90% do que provavelmente surgiria e fornecer um conjunto de campos não interpretados que podem lidar com todo o resto quando necessário. Ou seja, se o seu analisador falhar ao lidar com um endereço, salve-o sem análise e sinalizado como tal. Se você conseguir analisar um endereço, lembre-se da ordem em que encontrou os vários campos para que possa reagrupá-lo em algo a ser entregue.
Eu ia dizer que o campo mais importante será o código postal, mas mesmo isso não é um dado em muitos lugares.
Boa sorte. Isso pode ser um empreendimento divertido e extremamente frustrante, mas a chave para a sanidade é saber quando parar de tentar e apenas armazenar a entrada não analisada ou parcialmente analisada com a entrada original como backup.
Os problemas que podem ser resolvidos pela divisão incluem
Validação Qualquer parte do nome pode ser comparada a uma lista principal. Aqueles que não correspondem podem ser rejeitados. Código postal / código postal é um exemplo óbvio. Estes são emitidos e mantidos por uma autoridade independente. Os únicos válidos são aqueles emitidos por essa autoridade.
Classificação e seleção Já vi casos em que as tarifas postais são reduzidas se a correspondência for entregue ao serviço de entrega já organizado até certo ponto. Ter as colunas correspondentes produz valor comercial tangível.
Análise Pode ser útil saber para onde vão as suas encomendas, de forma geograficamente hierarquizada. Isso pode impulsionar iniciativas de vendas, desenvolvimento de produtos ou pagamentos de comissões, etc.
Duplicação de código Ao fazer com que todos os aplicativos em uma organização adotem o mesmo modelo de dados (aquele do consumidor mais complexo), uma única base de código pode ser adotada em toda a empresa e mantida de forma consistente. A divisão infinitamente duplicada do cabelo pode ser evitada ou, pelo menos, delegada às cabeças das hélices. Os endereços mantidos por diferentes partes da organização podem ser atualizados de forma consistente. O atendimento ao cliente e a satisfação podem ser aumentados. O esforço de desenvolvimento pode se concentrar nas partes exclusivas e de alto valor de um sistema.
Questões legais As leis e os impostos variam de acordo com a jurisdição. Ao capturar os valores de endereço detalhados separadamente, é mais fácil cruzar os dados transacionais com os requisitos de conformidade.
Duplicação É simples falsificar endereços mantidos como texto movendo um elemento para a próxima linha ou resequenciando algumas partes. Endereços totalmente analisados são mais fáceis de comparar. Isso pode ser um simples problema de qualidade de dados ou pode ter implicações de conformidade ou crédito se, digamos, várias empresas de fachada fizerem grandes pedidos para o mesmo endereço de entrega ou um cartão de crédito for usado para entregar em muitos locais dispersos em um curto período.
Formatação As partes mantidas separadamente podem ser combinadas de qualquer maneira que se adapte à necessidade atual. Se, digamos, etiquetas de impressão longas e finas ficarem baratas, você poderá reformatá-las para usá-las.
Claro que nada disso pode se aplicar a qualquer aplicação específica. Dados desse tipo são muito mais fáceis de analisar e validar na fonte, quando coletados, do que nunca na análise posterior. Portanto, mesmo se YAGNI, pode ser melhor colocar o esforço extra na frente por um custo baixo e uma grande economia futura potencial.
Por fim, não descartaria o fator humano. O modelo de dados é produzido por modeladores de dados. É o que eles fazem. Essa é a profissão deles. Eles não vão dizer para você apenas despejá-lo em um BLOB, vão?
Como todas as questões de design, há um "depende" extremamente qualificado. Depende da sua história de dados - como os dados são coletados, como são usados, como são atualizados etc. Todos os meus comentários devem ser considerados pontos de discussão, não respostas de instruções.
Parece que* você poderia se beneficiar mais usando um serviço de validação de endereço do que tentando criar um para você. Embora sejam caros, muitos desses serviços vêm com descontos significativos no envio de correspondência.
Claro, há um compromisso aqui, para certas histórias de dados. Você pode persistir as partes de endereço analisadas e criar uma coluna computada (conjunto de colunas, provavelmente) para o endereço combinado. Esta é uma resposta de implementação, com todas as ressalvas normais implícitas.
Eu implementei o design de endereço analisado. Nós absolutamente precisávamos disso para qualidade de dados E necessidades de processamento de dados. Mas era um negócio que tinha endereços físicos, endereços postais, endereços virtuais, etc.
A outra questão que pode surgir é que diferentes serviços postais exigem que as mesmas informações sejam apresentadas em diferentes formatos/encomendas/etc. Portanto, ter as peças modeladas ajuda a apresentar as mesmas informações em uma variedade de formatos e layouts.
Finalmente, você não precisa ter operações de negócios internacionais para dar suporte a dados internacionais. Mesmo as empresas com sede nos EUA precisam oferecer suporte a endereços internacionais. É um grande erro de dados presumir que você nunca terá isso. Os clientes mudam, os fornecedores mudam de sede, as informações de contato do fornecedor podem ser internacionais, mesmo que tenham uma sede nos EUA. Mesmo que seus sistemas atuais tenham cometido esse erro, você não deseja levar este adiante.
Eu recomendo fortemente os escritos e blogs de Graham Rhind. Ele é o especialista no campo de dados sobre endereços de todos os tipos e as compensações associadas a eles.
* Tudo o que eu disse aqui é uma generalização grosseira. Há tantas perguntas que eu teria para ajudar a chegar a uma solução de design que pode levar algumas horas de bate-papo. Provavelmente algumas fotos e alguns perfis de dados também. E então muitas histórias de dados realmente peculiares sobre endereços.
Deixando totalmente de lado o enorme desafio de analisar corretamente o jargão imprevisível que as pessoas fornecem, o benefício da análise é que ela fornece dimensões para agrupamento e classificação. Código postal, por exemplo. No entanto, não há recompensa em analisar uma dimensão específica até que você precise agrupar ou classificar nessa dimensão.
O que é um endereço, afinal? Você pode argumentar que é um identificador de localização, mas também pode argumentar que são instruções de entrega - "Na rua da fábrica de cimento". Na Austrália, as pessoas pensam que os códigos postais são identificadores de localização, mas não são, são códigos de roteamento - instruções de entrega. 4702 é Rockhampton Mail Centre, um importante nó de distribuição que atende uma região que se estende desde o mar até Emerald, uma cidade mineira 300 km para o interior.
Se você deseja identificar locais, o Bing e o Google podem geocodificar diretamente da string não analisada para as coordenadas do GPS, que podem ser armazenadas em uma tabela pequena e simples junto com a string não analisada. Eles usam a única abordagem geral com alguma chance de bons resultados consistentes: correspondência parcial ponderada classificada com um banco de dados colossal de resultados validados.
Se você quiser instruções de entrega, ainda é aconselhável manter a string não analisada porque ela pode conter qualquer coisa .
Observe que em ambos os casos eu recomendei manter a string não analisada. Isso é porque
Indiscutivelmente, um endereço é sempre instruções de entrega, contendo pelo menos um identificador de localização. Uma carta endereçada a "123 Main st, Emerald 4702" codifica três locais: RMC na parte norte de Rockhampton, Emerald e um endereço. Os correios de Rockhampton simplesmente enviarão para a RMC. RMC irá enviá-lo para os correios de Emerald, e esperamos que os correios de Emerald saibam onde encontrar a rua principal 123.
Separar o código postal/código postal, nome do edifício, nome da estrada pode fazer sentido. Mas então, quando você começa a adicionar “cidade”, “área” etc., fica questionável, em comparação com apenas linha1, linha2 etc. O problema é que mesmo eu e minha esposa não concordamos com o nome da cidade em que moramos! O nome da “aldeia” deve ser colocado no campo da cidade, ou vai na linha abaixo do nome da estrada, com a cidade local sendo colocada nos campos da cidade? (Algumas pessoas ficam ofendidas se você chamar o local de vila em vez de cidade, outras pessoas que moram no mesmo local ficam ofendidas se você chamar de cidade em vez de vila!)
Portanto, tentar fazer algo sofisticado não é melhor do que o sistema de verificação de endereço que você usa. Mas fica ainda pior. No Reino Unido, TODOS os endereços devem ter um código postal, mas o código postal não é alocado até algum tempo depois que uma casa é construída…… Portanto, um sistema deve permitir que todas as regras sobre endereço sejam quebradas!
Eu implementei um sistema como este antes, embora na Holanda. O problema é que esse tipo de informação pode mudar de mais maneiras do que você pensa. As ruas são renomeadas, as cidades são mescladas, os códigos postais são atualizados e assim por diante. É bom poder atualizar esse tipo de informação sem analisar os endereços como uma única string.
Além dos problemas já mencionados em outras respostas, em alguns idiomas - em particular o germânico - os nomes das ruas tendem a ser compostos. Por exemplo, é comum em muitas vilas / cidades alemãs ter uma "Bahnhofstrasse", a rua que vai para a estação ferroviária ("Bahnhof" significa estação ferroviária / ferroviária, "Strasse" significa rua). Certamente você poderia separar esses dois componentes, mas agora, se quiser juntá-los novamente (programaticamente), estará entrando em questões de declinação.
Ou, nas línguas "romance" ou latina, você frequentemente tem nomes de ruas na forma "Rue de la Pais" ou "Boulevard des Champs-Élysées". Agora você tem uma preposição ("de") e um artigo definido ("le" ou "la") na mistura -- e eles podem ser combinados. Eles representam parte do tipo de rua ou nome da rua? (Você provavelmente precisará armazená-los em algum lugar, caso contrário, estará entrando em declinação novamente.)
Certa vez, modelei algo assim. Mas era um aplicativo muito pequeno, para o escritório de manutenção de imóveis residenciais de uma universidade de médio porte (nos EUA). Tornei os endereços muito granulares pelos seguintes motivos:
... e outras razões que já não me lembro. (Isso foi no final dos anos 1980.)
E, novamente, isso só fazia sentido porque havia um número razoavelmente pequeno de endereços (e regras de formatação de endereço) para lidar. Não acredito que essa abordagem seja dimensionada, mesmo que limitada a endereços nos EUA, por motivos já apresentados em outras respostas.