Toda instrução SQL precisa ser revisada por um DBA - comum?

Quero dizer tudo, não apenas mudanças de esquema. Mesmo um SELECT simples em uma chave primária não pode entrar em produção, mesmo que tenha sido revisado por outros desenvolvedores (em contexto), sem uma revisão do DBA de cada instrução, extraída do código e enviada com saída EXPLAIN, detalhes de quantas vezes será chamado, etc, etc.

Se você já esteve em um ambiente assim, considerou um ganho líquido ou um empecilho para o desenvolvimento? Como alguém que trabalha com bancos de dados relacionais há anos, acho a atitude "não é confiável para os desenvolvedores usarem bancos de dados" injustificada e estou curioso para saber como essa situação é comum. Pelo que vale, isso é apenas para o desenvolvimento da web, não algo crítico.

Em um dos meus trabalhos anteriores, eu (junto com outros três programadores) fui responsável por revisar todos os procedimentos armazenados criados ou atualizados antes de entrar em produção para mais de 40 programadores. Como revisor, foi um empecilho para o meu tempo, mas no geral ainda era necessário, pois com isso muitos desenvolvedores cometem erros de vez em quando. Isso aconteceu porque tínhamos programadores externos que escreviam instruções SQL muito ruins (eficientes) e eles se recusavam a aprender (essa equipe acabou sendo desligada).

No geral, procuramos:

• Uso do índice - a consulta estava fazendo uma verificação completa da tabela?
• Manutenção - a consulta precisaria ser alterada em algumas semanas porque havia algo embutido nela? E a consulta é legível?
• Eficiência geral - uma junção interna poderia ser substituída por uma existente? Adicionar um bloco With ajudaria?
• Problemas de bloqueio - a consulta bloquearia o banco de dados e impediria que atualizações acontecessem? Isso aconteceu mais do que eu gostaria de pensar.

Na maioria das vezes, a maioria das consultas não apresentava problemas e continuamos. Mas cada revisão levou entre 10 minutos e duas horas, dependendo da consulta. Parte de mim gostou da ideia de fazer análises porque impediu a temida ligação telefônica às 2 da manhã, porque alguns relatórios estavam causando um problema com outro aplicativo. Mas, ao mesmo tempo, pensei que era um pouco exagerado, porque somos todos adultos e a pessoa que está escrevendo a consulta deve fazer tudo isso sozinha.

Acho que consultas complexas devem fazer parte da revisão de código padrão, mas não precisam passar por um DBA. Também não é necessário revisar instruções simples de inserção / atualização / exclusão. Além disso, como escritor de uma consulta, você deve saber quando ela ficou muito complexa e saber quando solicitar uma revisão de um DBA.

Atualização No meu primeiro trabalho, todas as consultas foram escritas por DBAs e isso foi uma grande perda de tempo no desenvolvimento. Eu tive que enviar todas as colunas que eu queria, tabelas onde as colunas estavam localizadas e, finalmente, meus critérios de pesquisa. Mesmo instruções básicas de inserção / atualização / exclusão são necessárias para passar por um DBA. Eventualmente, cheguei ao ponto em que eu poderia escrever o SQL que eu queria, fazer com que eles dessem uma olhada e fizessem as alterações necessárias e depois envolvessem um procedimento armazenado em torno dele, mas isso foi apenas alguns anos lá. Essa empresa em particular contratou muitos graduados recentes e foi assim que eles garantiram que os novos funcionários não escrevessem consultas que prejudicassem o desempenho.

Depende totalmente do meio ambiente, da indústria e da empresa.

Alguns exemplos:

• Na NASA, vários níveis de verificação e revisão são o padrão. O mais conhecido "deveria ter checado duas vezes" foi quando uma sonda foi enviada a Marte e os EUA fizeram cálculos em pés, mas os europeus em metros. A sonda foi perdida.

• Em uma inicialização sem DBA (comum hoje em dia), não haverá revisão do DBA e possivelmente nem revisão do programador (por exemplo, se não houver outros programadores na empresa).

• Em uma empresa cujo produto é um data warehouse de centenas de milhões de linhas, garantir que as consultas sejam eficientes e corretas pode ser um problema importante no núcleo da empresa que deve ser verificado.

Uma empresa cujo produto principal é um site principalmente estático, com um pequeno número de interações com o banco de dados, pode considerar o banco de dados e sua eficiência menos relevantes. Pode ser que a empresa decida gastar seu "orçamento" de revisão nas páginas estáticas consideradas mais críticas.

Eu nunca trabalhei em um ambiente como esse, tenho certeza que odiaria isso. Um pensamento vem à mente para começar a acompanhar algumas métricas em torno disso ...

• Quanto tempo um desenvolvedor gasta retirando o sql do código e preparando-o para ser submetido a um DBA
• Quanto tempo o DBA leva para revisar o sql?
• Com que frequência as alterações são solicitadas pelo DBA? Dividido por
  tipo de consulta ?

Acompanhar isso por um tempo provavelmente mostraria quanto de um arrasto ele é versus sua eficácia.

A maioria dos desenvolvedores é totalmente ignorante quando se trata de bancos de dados. Eles nem estão conscientes de sua ignorância. Eu costumava ser um desenvolvedor ignorante.

Os desenvolvedores vivem em um mundo de otimização é mau. Essa mentalidade não funciona quando você está executando operações em um disco. Essa mentalidade não funciona quando você escolhe um tipo de dados 8 vezes maior do que o necessário, o que faz com que o índice seja 8 vezes maior do que o necessário, para que não possa mais caber na memória. Essa mentalidade não funciona quando você programa em uma API genérica que atualiza redundantemente todas as colunas em uma tabela (não, obrigado Java beans).

Eles não sabem o que é uma verificação completa da tabela. Eles não sabem como processar dados em uma operação de conjunto único em vez de abrir um cursor. Pior do que um cursor, eles consultam dados e, em seguida, processam-na linha por linha, indo e voltando para o banco de dados quando uma única atualização simples e simples é suficiente. Resultando em desempenho HORRÍVEL.

Eles não sabem os graves impactos dos relatórios em tabelas grandes. Talvez a necessidade de relatórios exija a criação de um esquema em estrela e um feed de dados para ele. Seu desenvolvedor médio consultará apenas as tabelas existentes e se perguntará por que leva três horas para a consulta ser executada (esse é um valor real).

O conhecimento que seu desenvolvedor médio possui é suficiente para aplicativos CRUD "médios", nos quais um usuário simplesmente edita um registro. Não será suficiente quando eles saírem da bolha Ruby-on-Crack e entrarem no mundo real.

Depende do tamanho do banco de dados e se ele é compartilhado entre vários aplicativos. Freqüentemente, a equipe do DBA gosta de saber quais consultas serão executadas para garantir que os índices adequados estejam em vigor ou para saber quem notificar se precisar particionar uma tabela. E eles tendem a ser um pouco melhores do que o desenvolvedor médio na leitura de planos de execução de consultas e localização de lugares onde dicas podem ser especificadas para melhorar o desempenho. Também é uma chance de eles ficarem sabendo que algumas consultas de alto impacto serão lançadas no próximo lançamento, para que possam coletar estatísticas diferentes para o otimizador.

Eu não trabalhei em tal ambiente, nem eu.

Há uma diferença entre trabalho em equipe e burocracia hostil. Como desenvolvedor, eu adoraria ter a entrada do DBA em consultas difíceis. Mas eu sei quando pedir ajuda.

Se não sou competente o suficiente para SELECTconsultas simples , devo ser demitido.

Eu já vi isso em vários lugares diferentes. É ótimo em teoria, mas raramente vi ser eficaz. Aqui está o porquê. Em primeiro lugar, se você tem uma equipe de DBAs (ou outras pessoas), geralmente descobri que a pessoa menos competente ou menos apreciada do grupo recebe o peso do trabalho de revisão. Por que você diz? É porque, ninguém mais quer fazer isso, e todo mundo está ocupado fazendo outras coisas que provavelmente são mais urgentes. Já viu um DBA sentado e dizer: "Cara, tudo está funcionando perfeitamente; eu posso simplesmente sentar e navegar na Internet. Eu gostaria de ter algo para fazer". Eu também, pelo menos não os bons. Eles são tão ocupados ou mais ocupados que todos os outros. Isso significa que a pessoa menos capaz provavelmente está fazendo a revisão, e essa é exatamente a pessoa que você não deseja. O código que você deseja revisar é o código realmente difícil que as pessoas veem e o passam como algum tipo de magia negra. DBAs juniores ou simplesmente ruins, nunca serão capazes de captar as sutilezas de como uma consulta realmente difícil funciona. Raramente, como nunca, alguém diz: "Cara, eu não pensei em selecionar uma única linha de uma tabela usando a chave primária! Graças ao DBA, você é um salva-vidas". Portanto, nesse cenário, tudo o que você está fazendo é criar muito trabalho por pouco valor. pense em selecionar uma única linha de uma tabela usando a chave primária! Obrigado, DBA, você é um salva-vidas. "Portanto, nesse cenário, tudo o que você está fazendo é criar muito trabalho por pouco valor. pense em selecionar uma única linha de uma tabela usando a chave primária! Obrigado, DBA, você é um salva-vidas. "Portanto, nesse cenário, tudo o que você está fazendo é criar muito trabalho por pouco valor.

Em segundo lugar, é apenas mais trabalho para o grupo DB. O que provavelmente vai acontecer mesmo que eles olhem para outras coisas é que eles vão dar uma olhada rápida e algo vai perder. Eles são pessoas ocupadas, e revisar o código é realmente demorado. Na verdade, não é justo que eles se encarregem disso, porque é uma desculpa para que todos os outros sejam preguiçosos e os usem como saída, o que, em última análise, é o que acontece. Algo quebra na produção, e o desenvolvedor rapidamente aponta: "Bem, o DBA revisou". Agora isso é verdade o tempo todo, não, mas é verdade parte do tempo e geralmente das pessoas que precisam ter seu código realmente revisado. Então você enterrou o DBA com trabalho extra e forçou essa pessoa a ser responsável pelos erros de outra pessoa, quando essa pessoa provavelmente não '

A única maneira de realmente resolver o problema é ter pessoas que sabem escrever código SQL. Eles deveriam receber informações dos DBAs de tempos em tempos? É claro que deveriam, mas eu sempre achei que, se você não tem tempo para fazer o certo da primeira vez, quando vai encontrar tempo para consertá-lo.

Eu trabalhei nesse tipo de ambiente. Todas as alterações do sistema foram revisadas por pares apropriados. Para mim, isso significava que eu tinha que planejar com antecedência e enviar minhas alterações com alguns dias de antecedência. O SQL foi para os DBAs que lançariam o SQL em produção.

Meu SQL geralmente está bom, eles pegaram alguns erros tolos. Parece excessivamente burocrático a princípio, mas trabalho em finanças. Você viu o que acontece (se você está no Reino Unido) há alguns meses atrás, quando um grande banco estragou uma atualização de rotina e estragou todas as transações que levavam a milhões (pelo menos centenas de milhares) de pessoas incapazes de obter no dinheiro deles.

Eu iria ainda mais longe. Eu verificaria o código circundante e veria como as variáveis ​​são passadas para a consulta. É comum ver como os desenvolvedores expõem seu aplicativo a ataques de injeção de sql devido à falta de conhecimento básico (suposições falsas "isso não pode ser invadido").

Desenvolvedores inexperientes também podem arrastar o banco de dados de joelhos com um uso indevido do ORM ou uma consulta que está longe de ser ideal.

No projeto mais recente em que trabalho, nenhum desenvolvedor front-end tem permissão para acessar o banco de dados diretamente. Eles aumentam a demanda por uma função que retorna um determinado conjunto de dados e os desenvolvedores de back-end o preparam para eles. Está funcionando muito bem, os desenvolvedores do front-end escrevem a interface do usuário e processam os dados fornecidos pelas funções gravadas pelos desenvolvedores do back-end.

Em nossa equipe de desenvolvimento, há uma sub-equipe de 4 desenvolvedores de banco de dados com experiência na plataforma DBMS que usamos. Eles escrevem todo SQL ou pelo menos revisões e fazem alterações para atender aos seus padrões de codificação qualquer SQL gravado por desenvolvedores .Net. Eles fazem parte da equipe do projeto. Os DBAs de produção pertencem a um departamento completamente diferente e seu trabalho é operacional. Eles não revisam nosso código ou esquema SQL e até a implantação é com script, tudo o que fazem é executar o script. O máximo que eles ajudam é no ajuste de desempenho.