Várias respostas a uma pergunta de esquema do banco de dados sugeriram uma tabela adicional para normalizar um banco de dados para um recurso que não faz parte dos requisitos atuais (uma tabela UserDepartment para permitir um relacionamento muitos para muitos entre funcionários / usuários e diferentes departamentos que eles podem pertence a.).
Não contra a normalização. Parece que quando se trata de design de banco de dados, há um forte impulso para incluir recursos que eles 'têm certeza' de que alguém desejará no futuro. É tão difícil adicionar tabelas / campos ao banco de dados para acomodar recursos que há uma tendência a projetar demais? Eles não seriam refatorados ou atualizados, assim como o resto do aplicativo, se necessário? Refazer as coisas nunca é divertido, mas é possível mover dados de uma tabela para outra. Só não tenho certeza de onde essa linha de pensamento terminará.
Edit: Há tanta aversão a isso, eu me pergunto quantos projetos acabam não adicionando um recurso que requer uma alteração drástica no banco de dados ou são abordagens não normalizadas adotadas como adicionar um campo DepartmentID2 em vez de uma nova tabela. A necessidade de vários departamentos para um funcionário é um problema de domínio comum. Apenas não notei muitos esquemas de banco de dados repletos de relacionamentos muitos-para-muitos.