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.