Temos uma equipe que cria as tabelas e relações para desenvolvedores de software. Em nossa organização, eles são bastante rigorosos quanto ao cumprimento da normalização da 3NF - com a qual, honestamente, concordo com o tamanho da nossa organização e como as necessidades ou nossos clientes mudam ao longo do tempo. Há apenas uma área em que não estou claro sobre os motivos por trás de sua decisão de design: endereços.
Enquanto isso se concentra principalmente nos 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 recebe sua própria coluna na tabela de endereços. Por exemplo, considere este endereço gnarly dos EUA:
Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
Seria dividido no banco de dados como este:
- Rua: 485
- Fração da 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)
- Código Postal: 11111
- Código Postal: 2222
- País (supostamente EUA)
- Atenção: Jane Doe
- Caixa postal: NULL
- Tipo de habitação: APT (Apartamento)
- Número da habitação: 300B
E haveria algumas outras colunas relacionadas a rotas rurais e rotas de contrato. 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. Pesquisando on-line repetidamente refere-se ao uso das linhas de endereço 1, 2, 3 e possivelmente 4, e depois dividindo a cidade, região e código postal. Temos um caso de uso para o nosso novo aplicativo em que essa granularidade é benéfica. Temos que validar que o usuário não está criando um negócio duplicado e verificar o endereço é uma das validações. Nós podemos fazê-lo funcionar com a linha de endereço 1 e 2, mas seria mais difícil.
Quanto à nossa aplicação específica, precisamos armazenar vários tipos de endereços para empresas e pessoas (físico, correspondência, remessa etc.). Nós pode precisar gerar imprimíveis cartas de formulário, mas esta exigência não foi discutido até agora.
Outras coisas que os aplicativos da nossa organização precisam oferecer suporte:
- Auditoria (com tabelas completas do histórico)
- Impressão de 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 em que trabalho. Independentemente de nosso aplicativo se beneficiar, 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 possa entender melhor sua decisão de design e vender nosso cliente sobre a ideia ...
Quais problemas são resolvidos dividindo o endereço em colunas individuais?
Pontos de bônus para quem implementou um sistema como esse, porque eles tiveram problemas.