Executando verificação de segurança...
Em resposta a Como lidar com cliente relutante?
1
klawdyo

Eu faria uma outra abordagem:
Uma tabela users_roles poderia ter papéis vinculados ou não a empresas.
Ex.:

o usuário pode ser gerente na empresa 1
o dono pode ter permissão admin nas empresas 1, 2 e 3.
o suporte teria permissão de suporte em todas as empresas. poderia ser null no lugar da empresa.

Users
id: uuid
name: string

Roles
id: uuid
name: string
requires_business_id: boolean

Business
id: uuid
name: string

users_roles
id: uuid
user_id: uuid
role_id: uuid
business_id: uuid <-- não obrigatório
is_active: boolean

Dessa forma, você permitiria que o mesmo usuário tivesse n papéis em cada empresa. Inclusive, se um dia quiserem colocar um suporte que seja específico somente de 2 empresas, ou um gerente que possa visualizar 3 empresas, é possível com essa modelagem. Poderia deixar o business_id não obrigatório para que seja considerado como "todos". Quando o roles tiver o requires_business_id, então aquele perfil exige que seja informado uma empresa.

Essa modelagem é usada nos meus sistemas seguindo a mesma ideia, onde o mesmo usuário pode ser gerente de uma loja e atendente da outra, por exemplo. E os papéis de dev, admin e suporte são de toodos, então não precisaria informar uma loja.

Carregando publicação patrocinada...
1
Vanorton

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.

1
klawdyo
  • Autor
    Autor

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..