As respostas e comentários sobre a versão dba.se e a versão programmers.se da pergunta "Quais são os argumentos contra ou a favor de colocar a lógica do aplicativo na camada do banco de dados?" são muito reveladores sobre a divisão entre DBAs e programadores em alguns locais de trabalho.
O que os DBAs poderiam fazer de diferente para trabalhar melhor com os programadores em questões como essa?
Nós deveríamos:
- Estudar as ferramentas e linguagens que nossos programadores estão usando para entender suas dificuldades que enfrentam, principalmente ao trabalhar com bancos de dados bem projetados?
- Incentivar os programadores a serem mais instruídos sobre bancos de dados e as vantagens de ter lógica de negócios no nível do banco de dados?
- Mudar a forma como definimos interfaces para nossos dados - por exemplo, usando APIs transacionais mais amigáveis ao programador (por exemplo, para problemas como compatibilidade com versões anteriores)?
Eu tenho sido um MySQL DBA nos últimos 6,5 anos. Também passei cerca de 16 anos como desenvolvedor e interagi com muitos DBAs. Muitos deles pragmáticos. Alguns deles antipáticos. Alguns poucos não têm ideia do que significa ser um DBA.
Cheguei a esta conclusão:
Tecnicamente falando, os DBAs que possuem uma ou mais das seguintes qualidades são os melhores para se trabalhar:
DBAs muito disciplinados e experientes têm muito a compartilhar e oferecer. Eles podem ver o desempenho do banco de dados de uma perspectiva não realmente considerada pelos desenvolvedores. Os desenvolvedores sabem o que querem do banco de dados. Os DBAs sabem como ser "educados" com o banco de dados.
No que diz respeito às personalidades, sempre haverá conflitos, mesquinhez e talvez até inveja. Uma coisa é certa: em nenhuma ordem específica, DBAs e desenvolvedores são como maridos e esposas (estou casado e feliz há 16 anos com projetos em andamento [4 filhos]).
Independentemente de quem é visto como marido e quem é visto como esposa, estes princípios se aplicam:
Esses sete (7) princípios se aplicam tanto no local de trabalho, especialmente na área de TI.
Ao comunicar cada passo do caminho, todos devem:
Não há espaço para microgerenciamento nisso. DBAs NÃO DEVEM DIZER aos desenvolvedores como pensar como DBAs. Os desenvolvedores NÃO DEVEM DIZER aos DBAs como ser desenvolvedores. As decisões finais sobre desempenho e uso do banco de dados devem ser dos DBAs . As decisões finais sobre as necessidades do aplicativo devem ficar com os desenvolvedores . Essa simbiose deve ser mantida sempre.
PENSAMENTOS FINAIS
O princípio nº 7 requer participação ativa e supervisão da AUTORIDADE SUPERIOR (o HA), ou seja, gerente de projeto, líder de equipe, desenvolvedor líder. Seu HA sabe melhor como ambas as partes trabalham individualmente e como ambas as partes devem trabalhar juntas. Se o HA não estabelecer regras básicas para ambas as partes, ou se o HA não orientar as partes individualmente e em conjunto, os projetos sempre pararão em algum momento e colocarão em risco a própria existência (emprego) do Desenvolvedor, o DBA, ou mesmo o HA.
Ter times sentados em diferentes seções/pisos de alguma forma parece encorajar a mentalidade "nós contra eles".
Colocar um DBA bem no meio da equipe de desenvolvimento é uma ótima maneira de derrubar a barreira programador/DBA. Tanto o DBA quanto os programadores se beneficiarão com isso, se mantiverem a mente aberta e deixarem seus egos de lado.
A comunicação cara a cara, especialmente ao compartilhar ideias, é muito mais eficaz do que o e-mail e tem menos chance de causar ressentimentos devido a mal-entendidos.
Do ponto de vista do programador, eu diria que o que mais queremos são padrões consistentes, bem definidos e implementados de como a camada de dados será projetada e construída. Estou disposto a jogar do jeito que você quiser na sua caixa de areia, você só precisa me dizer o que quer, e não mudar as regras toda hora. Deve ser implementado da mesma forma para todos, até mesmo superprogrammergod. Se você abrir exceções para ele, então você quer que eu apoie e mude, mas reimplemente da maneira certa, o que não funciona para mim.
E, por favor, não me diga para não fazer dessa maneira e ir embora. Trabalhe comigo para me mostrar o que você quer e por que seu caminho é melhor. Se eu entender, cumprirei todas as vezes. Quando eu não entendo, é mais difícil obedecer. Eu não quero ser um DBA. Eu amo programar, não quero o seu trabalho e se você for um bom DBA, serei seu maior fã.
Esse tipo de coisa varia muito de lugar para lugar. No meu site atual, a linha entre desenvolvedores e DBAs é realmente muito tênue - nós (DBAs) também escrevemos PL/SQL e eles (desenvolvedores) dissecam os planos de consulta. Todos nós nos vemos como colegas, apenas com diferentes conjuntos de habilidades e responsabilidades. Isso é muito divertido: recentemente a empresa entrou na onda do DevOps . A comunidade de banco de dados não entende nada disso; sempre trabalhamos assim . Desnecessário dizer que somos extremamente produtivos trabalhando assim: a camada de banco de dados é de longea parte mais confiável da pilha de tecnologia da empresa, é fácil de operar (já que temos as habilidades na equipe de DBA para entender o aplicativo em um nível profundo e os desenvolvedores têm a exposição de DBA para entender as operações 24/7/365 e como estruturar seus aplicativos para isso).
Mas eu sei o que você quer dizer quando fala sobre o tipo "errado" de desenvolvedor. Ele é autodidata, o que por si só é uma coisa nobre, mas ao longo do caminho ele começou a desconfiar de qualquer tipo de instrução formal. Ele não sabe o que não sabe e se ressente de qualquer um que tente esclarecê-lo, ele vê isso como um insulto às suas habilidades de autoaprendizagem. Ele aprendeu o estilo imperativo de programação, porque você pode aprendê-lo sem nenhuma daquelas teorias sobre as quais os tipos de CS estão sempre tagarelando (bem, mal; todo mundo precisa saber grande-Oe pedaços semelhantes de teoria). Ele também aprendeu um pouco de OO, só porque precisa usar Java. Mas um bom profissional de banco de dados - desenvolvedor ou DBA - tem que se sentir confortável pensando em um estilo declarativo, pensando em teoria dos conjuntos, formas normais, até mesmo sendo capaz de entender a álgebra relacional e o cálculo. É muito, muito difícil se comunicar com essas pessoas, porque elas são ativamente hostis a qualquer coisa que possa tirá-las de sua zona de conforto, que é em geral limitada a como formatar algo em uma página da web. Se eles pensarem em bancos de dados, eles pensarão que uma tabela é como uma classe e uma linha é como um objeto. Esses caras vão literalmente fazer
SELECT * FROM TABLE, filtrar e classificar os resultados em seu próprio código. Eles realmente não entendem por que um banco de dados é melhor do que um arquivo simples (e eles não tão secretamente pensam que qualquer um que usa um banco de dados relacional é um idiota).Deixe-me dar um exemplo real: recentemente eu estava conversando com um desses tipos sobre os problemas envolvidos na reversão de um lançamento de nosso software depois que ele entrou em produção, se um problema passou do controle de qualidade. Expliquei que, embora possamos reverter seu aplicativo (um dos muitos que acessam o banco de dados), ele precisa ser capaz de operar com o banco de dados ainda implantado. Ele perguntou por que, e eu disse, bem, nessas novas tabelas e colunas, haverá dados reais de clientes. Ele então disse, então apenas copie para uma tabela temporária, qual é o problema. Olhei para ele sem acreditar: quando um cliente liga e diz, meu dinheiro sumiu da minha conta, o que dizemos a ele, que está tudo bem, está em uma mesa temporária? Ele simplesmente não entendeu que quando você está lidando com o dinheiro de outras pessoas, você tem que agir como um adulto responsável. Pelo que sei, ele ainda não sabe; ele não está mais conosco.
O acampamento MySQL foi assim por muito tempo; eles diriam que você não precisava de transações, chaves estrangeiras, etc, se você pensasse que precisava, era apenas porque não tinha ideia do que estava fazendo, etc, etc (então, quando eles cresceram, eles os adicionaram silenciosamente). Esses são os tipos de pessoas para as quais ORMs como ActiveRecord ou Hibernate foram desenvolvidos, para que pudessem escrever aplicativos de banco de dados sem precisar tocar em SQL. Considero o uso dessas tecnologias uma bandeira vermelha - esta não é uma empresa que valoriza as habilidades de DBA. O que eles realmente querem é uma babá...
Como programador, entender melhor o banco de dados me tornou um programador melhor. Quando me tornei um administrador de banco de dados, isso se tornou ainda mais importante, portanto acredito que a educação é a chave.
Os DBAs devem orientar pacientemente os desenvolvedores, tratando-os como profissionais competentes. Poucos programadores, ao verem a diferença entre uma operação definida e uma operação linha por linha no lado do cliente, hesitarão diante da ideia. Compartilhamos alguns dos mesmos objetivos - velocidade do aplicativo, segurança de dados, capacidade de manutenção, etc. Isso se aplica não apenas à questão da lógica do aplicativo, mas também a todos os aspectos da interação com o banco de dados. Os programadores querem usar melhor suas ferramentas e quanto mais o DBA puder mostrar a eles como usar melhor a ferramenta de banco de dados, mais ambos se beneficiarão.
Independentemente da infraestrutura que suportamos, temos que oferecer suporte aos usuários dela. Muitos usuários são desenvolvedores, então damos suporte aos desenvolvedores para permitir que eles façam o melhor uso possível dessa infraestrutura. Para poder fazer isso, precisamos entender uns aos outros, com as diferentes ideias e pontos de vista em mente. Ter uma visão dos pontos de vista de ambos os lados ajuda a melhorar as coisas para os negócios e esse é o nosso objetivo combinado. Tornar o suporte de TI aos negócios o mais eficaz possível.
Em muitas organizações, vemos alguns tipos de dba sendo executados no modo deus. Na maioria das vezes, esses não são os que pontuam muito bem se a competência for medida ... Freqüentemente, eles apenas escondem sua - falta de - conhecimento atrás de uma parede de palavras.
Na minha opinião, não tem nada a ver com ser 'amigável ao programador' e sim com ser profissional. Para um dba, isso significa que precisamos ser capazes de explicar por que fazemos as coisas que fazemos e estar preparados para, pelo menos, reconsiderar a decisão se isso ajudar, sem perder os objetivos normais, como disponibilidade, escalabilidade, capacidade de recuperação e desempenho. Para o programador, significa que ele deve se comunicar com o dba, às vezes para ensinar o dba, às vezes para aprender com o dba. Meu lema sobre isso é: que o primeiro dia em que eu não aprender nada seja o dia em que o caixão se feche sobre minha cabeça. Colaboração normal, tendo equipes combinadas com desenvolvedores e dba certamente ajudam a tornar as coisas mais fáceis.
Acho que parte do problema é a perspectiva. Dbas e analistas de dados e desenvolvedores de banco de dados precisam lidar com os dados ao longo do tempo. Os desenvolvedores de aplicativos se preocupam em como fazer as coisas funcionarem quando as enviam para produção. Eles não se preocupam tanto com a aparência dos dados em seis meses, desde que não haja erros quando forem implantados.
Mas as pessoas que trabalham com dados precisam conviver com os resultados de decisões míopes que fazem com que os dados percam a integridade ou que registros duplicados sejam inseridos e depois tentam explicar por que os dados são ruins. DBAs é quem tem que lidar com o problema de performance do processo que funcionava bem quando havia apenas mil registros, mas agora leva horas com 100.000.000 de registros.
Os bancos de dados são mais difíceis de refatorar, portanto, os DBAs se preocupam em acertar na primeira vez. Os desenvolvedores não veem problemas em refatorar no futuro.
Os desenvolvedores não veem nenhum problema em fazer o banco de dados agir como se fosse orientado a objetos, o pessoal do banco de dados sabe que essa não é a maneira mais eficaz ou eficiente de armazenar ou obter os dados.
Os desenvolvedores de aplicativos geralmente lidam apenas com um pequeno subconjunto de registros, mas não com grandes importações/exportações de dados ou relatórios. Coisas que funcionam bem para inserir um registro, não funcionam quando você está falando sobre importar um milhão. A lógica de negócios no aplicativo (que geralmente não é acessível para o aplicativo de relatório) não ajuda o redator do relatório a obter os mesmos resultados para um milhão de registros que são mostrados na tela, um registro por vez.
Outra parte do problema é o desrespeito de ambos os lados. Eu conheci mais do que alguns desenvolvedores de aplicativos que acham que o trabalho com dados não é difícil ou interessante e que acreditam que você só faria esse trabalho se não pudesse hackeá-lo em seu mundo. As pessoas tendem a não reagir bem ao serem tratadas como se fossem estúpidas e inúteis. Alguns DBAs, por outro lado, também tendem a tratar os desenvolvedores de aplicativos com desrespeito e tendem a colocar suas tarefas de revisar o que os desenvolvedores estão fazendo no banco de dados como uma prioridade baixa (o que pode ser quando você tem bancos de dados de produção grandes e complexos). Eles podem se recusar a ouvir ou responder. Quem quer que todo o seu projeto seja suspenso até que o DBA o revise duas semanas depois? E então ele diz que é inaceitável e você tem que reescrever tudo?
Ao longo dos muitos anos desde que comecei com o SQL Server (1998), muitos desenvolvedores me disseram como fazer meu trabalho. É interessante que todos eles saibam mais do que eu, além de serem excelentes desenvolvedores .net. Na verdade, eles também são arquitetos e deveriam fazer coisas maiores do que codificar.
Talvez essa seja a atitude errada de minha parte: mas é uma atitude de desenvolvedor bastante comum em muitas lojas. Eles também fazem isso uns com os outros, lembre-se: assista as brigas começarem quando você sugerir revisões de pares.
Vou deixar as correções para outras respostas (concordo 100% com as 2 até agora), mas acrescento que a gestão e a cultura da loja também devem apoiar e nutrir a colaboração.
Como desenvolvedor, tudo que preciso de você é saber como você quer que eu comunique o que preciso. Se estou pedindo algo ridículo, preciso que você me diga - e se você me disser, acreditarei porque você tem um histórico de integridade. Se você não entender o que estou pedindo, reserve um tempo para me explicar o que você acha que quero dizer - e eu dedicarei um tempo para ouvir.
... Tema comum, né ... Comunicação ... comunicação ... comunicação.
Não há realmente nenhuma maneira melhor de colocá-lo. Os desenvolvedores ficam irritados porque "aquele DBA me disse que não poderia ser feito - com certeza provei que ele estava errado da última vez". Os DBAs ficam irritados porque "aquele desenvolvedor não entende o que tenho que fazer toda vez que ele muda suas especificações".
Desenvolvedores e DBAs, como disse @Rolando, precisam se entender. Quando tudo se resume a isso, nós dois falamos "Uns & Zeros" - você pensaria que seria uma boa combinação. Temos 2 domínios de responsabilidade: os DBAs têm dados, os desenvolvedores ficam com o resto do computador. Mas sem dados, os programadores realmente não teriam muito o que fazer.
Não temos um DBA e às vezes é doloroso. Aquele pedaço de mim que queria ser um DBA uma década atrás vai se encolher quando vir algumas das coisas que fazemos. Se contratássemos um DBA amanhã, acho que beijaria o chão que ele pisou.
Em algumas empresas, talvez muitas, o desenvolvimento de produtos tende a ignorar qualquer um que não escreva em uma linguagem compilada. Na hora do lançamento, há resistência porque administradores de rede, DBAs, administradores de sistema, suporte ao usuário, etc., cada um tem sua devida diligência para concluir. Muitas vezes há dores de cabeça porque os principais aspectos do ambiente não foram considerados. Isso naturalmente causa tensões entre as equipes.
Quem é o culpado aqui? Sra. Comunicação.
Os desenvolvedores precisam entender o código do ambiente em que serão implantados. As pessoas precisam receber um aviso justo para se adaptar. Onde o ambiente não pode se adaptar por qualquer motivo (segurança, equipamento, política), o software precisa se adaptar. Se isso acontecer durante o processo de design e implementação, todos ficarão felizes. Se não começar até o momento da implantação, é um mundo de dor.
Sim, as equipes precisam conversar (e ouvir) umas com as outras, mas o gerente de projeto/produto precisa criar um ambiente no qual isso possa acontecer.
Tive sorte, na maioria dos lugares onde trabalhei, o respeito mútuo e a comunicação fizeram parte da cultura.