Os desenvolvedores precisam ter acesso de leitura a todos os bancos de dados, incluindo prod. Às vezes, o problema é que os dados no Prod não são o que eles esperavam ter e eles precisam ver os dados que estão causando o problema, pois não podem reproduzi-los no dev.
Os desenvolvedores não devem ter direitos de gravação de dados de produção ou direitos para criar objetos. Não deve acontecer nada que não faça parte de um lançamento oficial. Muitas vezes, as pessoas corrigem rapidamente o produto que não funciona, fazendo com que o produto fique ainda mais mole ou funcione, mas esquecem de colocar o código nos servidores dev / QA / Staging e, pior ainda, na fonte repositório de controle e o código será sobrescrito cerca de um mês depois no próximo lançamento oficial.
Prefiro que os desenvolvedores tenham direitos completos de controle de qualidade do banco de dados porque a implantação em outro servidor os ajuda a ver se há alguma lacuna no processo de implantação (opa esqueceu que eu alterei a tabela para fazer isso e tal e oops, esqueci que fiz essa alteração usando a GUI e não em um script no controle de origem, que é como todas as alterações estruturais do banco de dados precisam ocorrer).
Quando você tem um novo cliente do tipo Enterprise que possui seu próprio conjunto de servidores, as permissões podem ser facilitadas antes da entrada em operação. Isso ocorre porque muita coisa precisa acontecer e as poucas pessoas que podem fazer isso acontecer no produto são acumuladas e, às vezes, precisam tirar uma folga. Em particular, as pessoas que estão importando dados de outro sistema podem receber a tarefa de colocá-los em produção antes do lançamento, se o carregamento de dados demorar muito. Essas pessoas tendem a ser especialistas em dados e há um nível de conforto mais alto ao permitir acesso temporário ao produto do que o desenvolvedor médio de aplicativos. Este não é um luxo que você tem ao acessar um servidor de produção já ativo.
Uma das coisas mais críticas sobre como limitar os direitos de produção ao banco de dados é que os desenvolvedores precisam garantir que seu trabalho esteja em um formato que possa ser implantado por outra pessoa. Isso tende a melhorar a qualidade do trabalho, porque eles não estão tentando fazer correções instantaneamente, porque se esqueceram de algo ou algo não funcionou, porque fizeram isso de maneira diferente em prod do que quando se baseavam apenas na memória. Você também perde aqueles "ops, eu apaguei a tabela inteira do usuário por acidente, porque eu esqueci de destacar uma cláusula where" do tipo de acidentes quando implantações de produtos usam apenas scripts que são executados como um todo, não um comando por vez, como é típico quando desenvolvedores executar as coisas no prod. Uma equipe com direitos limitados para produzir bancos de dados é mais provável que também armazene alterações no controle de origem.