Pegue a representação de um endereço, abaixo está uma implementação completa e muito detalhada:
aqui, em vez disso, é uma implementação rápida (que contém mais ou menos os mesmos campos, imagine que todos os campos do primeiro também estejam contidos no segundo)
Se eu fosse decidir qual é o mais próximo de um normalizado e academicamente correto, eu diria o primeiro, mas se eu fosse iniciar um projeto, iria com o segundo.
Você concorda com esta consideração? E se sim, como se lida com esse fato?
- comece com um banco de dados fácil e, assim que for a hora, melhore-o para um banco de dados mais normalizado/acadêmico.
- comece com algo o mais próximo possível do banco de dados acadêmico
- ficar com a solução rápida e suja
Tentar normalizar endereços geralmente é uma má ideia. Não há muito valor em normalizar endereços. Ambos os designs são inadequados para a grande maioria dos sistemas.
Há duas coisas que você normalmente faz com endereços:
Como você está usando estados, províncias e distritos em seu projeto, e não prefeituras, por exemplo, presumo que você esteja trabalhando em um contexto norte-americano. Se isso for verdade, então você tem autoridades postais bem estabelecidas (USPS, CPC) com dados postais muito bem regulamentados e ferramentas de qualidade de dados de endereço prontamente disponíveis. Mesmo se você estiver trabalhando fora dos EUA/Canadá, provavelmente existem ferramentas de qualidade de dados que farão o que você precisa.
Com a validação e padronização de seus dados de endereço, você pode ter certeza de que conseguirá atingir sua primeira meta.
Usando o CEP+4 nos EUA e o código postal em muitos outros países, você pode obter tudo o que precisa para sua segunda meta.
Muitas pessoas são realmente tentadas a dividir os endereços em campos granulares. Esta é uma reação a como os dados de endereço geralmente são ruins quando tudo o que você tem é "address_line_1, address_line_2,...". No entanto, colocar nomes de cidades ruins e não validados em seu próprio campo significa apenas que você tem uma pilha menor de lixo em vez de uma pilha maior. A única maneira de resolver isso é usar uma ferramenta de qualidade de dados de endereço para validar e padronizar seus endereços. Se você tentar normalizar seus dados de endereço, acabará com uma grande pilha de associações muitos-para-muitos. Isso ocorre porque os endereços na vida real não se encaixam nas hierarquias organizadas que você veria em um livro didático.
A menos que você tenha alguma necessidade realmente especializada de endereços, apenas mantenha suas tabelas simples (algumas linhas de endereço, talvez com o código postal quebrado) e obtenha uma boa ferramenta de qualidade de dados de endereço para limpar os dados no caminho.
Minha preferência seria algo no meio. Como estados/províncias e países são entidades bem estabelecidas que não mudam com o tempo, você pode retirá-los em tabelas separadas. No entanto, tentar normalizar os dados de nível de rua e cidade enquanto confia na entrada humana é, na melhor das hipóteses, propenso a erros e, na pior das hipóteses, você acabará com algumas informações muito ruins em seu banco de dados.
Acho que a "maneira academicamente correta" não é fornecer funcionalidade para todos os detalhes que possam se apresentar no objeto da vida real que você está modelando. Acho que significa simplesmente que -se- você precisa desse nível de detalhe, -isto- é agora que você deve normalizá-lo.
Indo na mesma direção da "solução 1", você também pode começar a criar tabelas para locais que receberam um novo nome ao longo do tempo ou regiões que foram absorvidas por outras regiões vizinhas ao longo do tempo. Você poderia implementar detalhes ao infinito.
Portanto, a questão é -sempre-, qual funcionalidade você precisa e qual é a maneira mais simples de implementá-la de forma normalizada. A solução "rápida e suja" parece perfeitamente normalizada para mim, se essa é a funcionalidade que você está procurando.