Sempre usei direitos de acesso do usuário como um conjunto (de bits) no código e os armazenei como vários bigints (dependendo de quantos eu precisava).
Estes são direitos como
- Permitido visualizar registros de clientes
- Permitido criar registros de clientes
- Permitido editar registros de clientes
- Permitido excluir registros de clientes
- Permitido executar relatórios de clientes
- Permitido registrar um celular
- Permitido visualizar o painel
Portanto, eles não estão relacionados apenas a bancos de dados.
Vejo que eu poderia armazená-lo como um array JSON de descrições, mas isso poderia ficar muito grande (e talvez lento). Eu poderia usar uma sigla de 4 letras para cada um.
Existe uma terceira maneira de fazer isso para minimizar a verbosidade no código?
Existem fundamentalmente duas soluções diferentes:
Armazene todas as permissões para cada usuário em uma única linha ou armazene as permissões em várias linhas.
Com uma única linha
Há algumas soluções diferentes para escolher, além das duas que você descreveu na pergunta:
ALTER TABLE
o que é um não-não).SET
. Ela tem as mesmas desvantagens que 1, e adicionar índices só é possível via colunas virtuais.Com várias linhas
Você poderia ter, por exemplo:
person
mesapermission_type
tabela (com umatype
varchar
coluna que identifica exclusivamente o tipo de permissão para seu aplicativo e umadescription
coluna que o descreve em mais palavras para humanos)person_has_permission_type
mesa de junção.As vantagens são que os índices são fáceis e você pode facilmente adicionar novos tipos de permissão por meio do aplicativo. Você provavelmente acabará com mais linhas do que com as outras soluções, mas depende. Por exemplo, talvez a maioria dos usuários não tenha permissões ou apenas uma permissão.
O que todas as soluções acima têm em comum, e que é melhor do que sua solução de bits armazenados em bigints, é que você pode entender quais permissões um usuário tem apenas olhando o banco de dados, ou seja, você não precisa do código do aplicativo para ler/interpretar as permissões.
Também seria possível combinar algumas soluções, por exemplo, você poderia ter alguns tipos de permissão que você sabe desde o início que definitivamente precisará definidos como colunas separadas na
person
tabela, como talvezread_write_all boolean
(super admin) eread_all boolean
. E então combinar isso com a solução de várias linhas para que o restante dos tipos de permissão possam ser gerenciados pelo seu aplicativo.