Estou usando o PostgreSQL e projetando um esquema de banco de dados relacional para um aplicativo onde desejo armazenar dados definidos pelo sistema (integrados) e dados definidos pelo usuário (personalizados) em várias tabelas, por exemplo:
Categorias de produtos
| eu ia | nome | organização_id |
|---|---|---|
| 0 | Vegetais | 068fd6a5-1c93-493f-9ffc-93a52de02aa8 |
| 1 | Laticínio | 068fd6a5-1c93-493f-9ffc-93a52de02aa8 |
Os dados definidos pelo sistema são pré-preenchidos e devem ser imutáveis pelos usuários, enquanto os dados definidos pelo usuário podem ser criados, modificados e excluídos pelos usuários. Preciso ser capaz de consultar dados do sistema e do usuário separadamente e gostaria que os clientes permanecessem burros.
Eu considerei as seguintes abordagens:
- Adicione uma coluna booleana (por exemplo,
is_system) para indicar se os dados são definidos pelo sistema ou pelo usuário, mas como uma porcentagem incrivelmente baixa de registros será definida pelo sistema, não tenho certeza se isso é uma boa ideia. - Use tabelas separadas para dados definidos pelo sistema e dados definidos pelo usuário, mesmo que a estrutura seja quase idêntica. Isso parece errado para mim, pois os dados são essencialmente os mesmos.
- Adicione uma organização “de propriedade do sistema” e identifique os dados definidos pelo sistema usando seu ID. Os clientes precisariam ser menos burros, porque agora têm um ID para lembrar se quiserem consultar dados do sistema.
Qual abordagem é geralmente recomendada? Existem outras estratégias que devo considerar?
Obrigado por seus insights.
Como a sua preocupação é de segurança, ou seja, restringir quem pode fazer o quê com diferentes dados, a mais simples é a sua segunda opção: manter os dados do seu “sistema” em tabelas separadas, com diferentes controles de acesso. Por exemplo, mantenha-os em um esquema separado = de propriedade do usuário com permissão para atualizar esses dados, mas legível por todos os outros usuários. Dessa forma, os controles de acesso são aplicados automaticamente pelo seu banco de dados. Este mecanismo funcionará com qualquer banco de dados relacional.
A primeira e a terceira opções implicam que todas as consultas e atualizações devem incluir predicados adicionais para isolar o sistema de outros dados. Isso torna as consultas mais complexas de escrever e coloca os requisitos de segurança no código do aplicativo que acessa os dados.
Alguns bancos de dados (como Oracle) possuem recursos que permitem proteger linhas individuais em uma tabela, identificadas por meio de um predicado (= baseado no valor da coluna como o sinalizador “is_system”), chamado “segurança em nível de linha”. Essa pode ser uma opção se você usar um desses bancos de dados.