O Django precisa de acesso total ao banco de dados subjacente, se você quiser usar todos os seus recursos como migrações . Portanto, é recomendado nos documentos conceder todos os privilégios.
Existem casos de uso em que você pode querer restringir o acesso - por exemplo, se você tiver um esquema não gerenciado, que é compartilhado com outros aplicativos. Mas isso é bem especial. Esses tópicos não são cobertos pelos documentos e são deixados para você como DBA.
Se você sabe quais privilégios são necessários para o seu django - apenas conceda-os como quiser.
Se você não souber quais privilégios são necessários, use o seguinte procedimento:
- Configure seu projeto no contexto de desenvolvimento, usando um usuário totalmente autorizado.
- Crie um novo usuário e não conceda nenhuma permissão
- Mude seu django para usar esse usuário
- Inicie seu aplicativo, use seus recursos e aguarde erros de SQL.
- Conceda as permissões necessárias
Repita as etapas 4. e 5. enquanto tudo funcionar - grave todas as concessões em um arquivo sql, para poder reproduzir isso mais tarde. Claro que você pode acelerar o processo, concedendo coisas na frente, se você já sabe, que é necessário.
Você provavelmente vai precisar
SELECT
em quase todos os casosINSERT
se os usuários puderem criar um modeloUPDATE
se os usuários puderem modificar um modeloDELETE
se os usuários puderem excluir um modeloREFERENCES
se os usuários criarem um modelo com restrições de chave estrangeira para outro modelo -REFERENCES
é necessário para este outro modelo.
O que é necessário no caso de sua aplicação é algo que só você sabe. Talvez
SELECT
é suficiente, quando você apenas fornece acesso legível aos seus dados. Quando você trabalha assim, você deve ter um usuário separado, usado para implantação, que tenha direitos apropriados para executar suas migrações (conceder todos os privilégios neste caso faz sentido). Isso se aplica a cada versão e deve ser automatizado IMO.