Entendi seu modelo, ficou bom, mas os usuários comuns pertencem a uma única empresa e não existe hoje cenário de usuário com múltiplos papéis em empresas diferentes no sistema saca?
Minha proposta é pra resolver o problema real de agora com a menor complexidade possível, mantendo espaço para evolução futura. Se nem a separação ele tá querendo aceitar, imagina se eu mostrar esse modelo pra ele kkkkkkk.
Mas valeu cara, só tô vendo ainda mais que o modelo que ele quer não escala nunca.
Respondendo a "Eu faria uma outra abordagem: Uma tabela users_..." dentro da publicação Como lidar com cliente relutante?
1
1
Mas os exemplos de múltiplos papéis em empresas diferentes foram apenas exemplos. Não necessariamente você precisa usar. A questão é que você precisa definir de alguma forma quais usuários se ligam a que.
E o relacionamento n:n é a melhor escolha. Gambiarra zero e escalável. Ainda que sua interface não reflita isso, é interessante que você deixe uma base pra não mexer nos dados futuramente.
Como no exemplo: digamos que uma empresa com múltiplas filiais contrate o sistema amanhã. Ou uma empresa de empresas. O cara pode querer que um funcionário possa visualizar várias.
A chance de deixar os dados escaláveis é agora, mesmo que a sua interface não mostre a opção .
Com a modelagem correta, tu só meteria um select no topo e tava resolvido. Sem isso, você teria que mudar dados, migrations etc.
Eu, particularmente, mesmo não resolvendo coisas que não fui contratado, sempre deixo ganchos preparados para uma escala. Ainda que a interface não mostre.
Mas enfim..