Meu conselho sobre modelagem de dados é:

• Você deve favorecer colunas opcionais (anuláveis) em vez de junções 1:1 de um modo geral . Ainda há casos em que 1:1 faz sentido, geralmente girando em torno da subdigitação. As pessoas tendem a ser mais melindrosas quando se trata de colunas anuláveis ​​do que estranhamente sobre junções;
• Não faça um modelo também indireta, a menos que realmente justificado (mais sobre isso abaixo);
• Favor de junções em vez de agregação. Isso pode variar, por isso precisa ser testado. Consulte Oracle vs MySQL vs SQL Server:agregação vs Associações para um exemplo disso;
• As junções são melhores que as seleções N+1. Uma seleção N+1 é, por exemplo, selecionar um pedido de uma tabela de banco de dados e, em seguida, emitir uma consulta separada para obter todos os itens de linha desse pedido;
• A escalabilidade das junções é geralmente apenas um problema quando você está fazendo seleções em massa. Se você selecionar uma única linha e depois juntá-la a algumas coisas, raramente isso é um problema (mas às vezes é);
• As chaves estrangeiras devem sempre ser indexado, a menos que você esteja lidando com uma tabela trivialmente pequena;

Mais em Erros de desenvolvimento de banco de dados cometidos por AppDevelopers .

Agora, quanto à franqueza de um modelo, deixe-me dar um exemplo. Digamos que você esteja projetando um sistema para autenticação e autorização de usuários. Uma solução com engenharia excessiva pode ser algo assim:

• Alias ​​(id, nome de usuário, user_id);
• Usuário (id, ...);
• E-mail (id, user_id, endereço de e-mail);
• Login (id, user_id, ...)
• Funções de login (id, login_id, role_id);
• Função (id, nome);
• Privilégio de função (id, role_id, privilégio_id);
• Privilégio (id, nome).

Portanto, você precisa de 6 junções para ir do nome de usuário inserido aos privilégios reais. Claro que pode haver um requisito real para isso, mas na maioria das vezes esse tipo de sistema é colocado por causa da preocupação de alguns desenvolvedores pensando que um dia eles podem precisar, mesmo que cada usuário tenha apenas um alias, o usuário para fazer login é 1 :1 e assim por diante. Uma solução mais simples é:

• Usuário (id, nome de usuário, endereço de e-mail, tipo de usuário)

e, bem, é isso. Talvez se você precisar de um sistema de funções complexo, mas também é bem possível que não precise e, se precisar, é razoavelmente fácil inserir (o tipo de usuário se torna uma chave estrangeira em uma tabela de tipos ou funções de usuário) ou geralmente é simples mapear o velho para o novo.

Isso é uma questão de complexidade:é fácil de adicionar e difícil de remover. Geralmente é uma vigília constante contra a complexidade não intencional, o que é ruim o suficiente sem ir e piorar adicionando complexidade desnecessária.