Pelo ID do grupo, por tenant

Ao invés de ter uma primary key simples, eu faria a mesma pelas colunas tenant_id e id, sendo o id incremental para cada tenant.

Dessa forma você consegue ter um id que faz sentido sequencialmente. (vamos supor que o usuário vá usar esse id do grupo com frequencia, seria chato ele yer que lidar com um id 97643 ao invés de 8)

Com UUID

Se o usuário não precisar decorar o id, o problema é resolvido usando um UUID como chave primária.

A vantagem é que você não precisa lidar com uma primary key complexa, além de tornar mais difícil (virtualmente impossível) vazar informações entre os tenants caso o middleware falhe por exemplo.

ownerczx

8 meses atrás

Obrigado pelas ideias.

O usuário não precisa decorar o id, então acredito que a forma do UUID seja uma recomendação válida.

silvestrini

8 meses atrás

Acredito que não basta ser UUID para garantir a segurança, se o usuário conseguir de qualquer forma descobrir o uuid, conseguirá acessar as informações.

Acaba que é necessária uma validação a mais para garantir que seja do mesmo tentant, então tanto faz se é id ou uuid, o trabalho será o mesmo.

Já o uuid possui algumas desvantagens:

Não é autoincrement, você terá que criar uma forma de gerar a string.
Os relacionamentos se tornam mais complicados de serem feitos, justamente por ser string.
Fica gigante na URL caso trabalhe com rotas aninhadas

Aí vai da sua necessidade e verificar qual o caminho que mais vale a pena.