Esse tipo de coisa varia enormemente de um lugar para outro. No meu site atual, a linha entre os desenvolvedores e os DBAs é muito turva - nós (os DBAs) também escrevemos PL / SQL e eles (os desenvolvedores) dissecam os planos de consulta. Todos nós nos vemos como colegas, apenas com diferentes habilidades e responsabilidades. Isso é muito divertido: recentemente, a empresa entrou na onda do DevOps . A comunidade do banco de dados não entende nada disso; nós sempre trabalhamos assim. Escusado será dizer que somos extremamente produtivos trabalhando assim: o nível do banco de dados é de longea parte mais confiável da pilha de tecnologia da empresa, é fácil de operar (já que possuímos as habilidades da equipe do DBA para entender o aplicativo em um nível profundo, e os desenvolvedores têm a exposição do DBA para entender as operações 24/7/365 e como para estruturar seus aplicativos).
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 desconfia de qualquer tipo de instrução formal. Ele não sabe o que não sabe e se ressente de alguém tentando esclarecê-lo, ele vê isso como um insulto às suas habilidades de auto-aprendizado. Ele aprendeu o estilo imperativo da programação, porque você pode aprender sem nenhuma dessas teorias sobre as quais os tipos de CS estão sempre tagarelando (bem, mal; todo mundo precisa saber muito bem)e pedaços de teoria semelhantes). Ele também aprendeu um pouco de OO, apenas porque precisa usar Java. Mas um bom profissional de banco de dados - desenvolvedor ou DBA - precisa se sentir confortável pensando em um estilo declarativo, pensando em teoria dos conjuntos, em formas normais e 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, o que geralmente se limita a como formatar algo em uma página da web. Se eles pensam em bancos de dados, pensam que uma tabela é como uma classe e uma linha é como um objeto. Esses caras literalmente fazem, SELECT * FROM TABLEfiltram e classificam os resultados em seu próprio código. Eles realmente, realmente não entendem por que um banco de dados é melhor que um arquivo simples (e eles não pensam tão secretamente que qualquer pessoa que use 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 uma versão do nosso software após a entrada em produção, se um problema tivesse passado pelo controle de qualidade. Expliquei que, embora possamos reverter seu aplicativo (um dos muitos que acessam o banco de dados), seria necessário poder operar com o banco de dados ainda implantado. Ele perguntou por que, e eu disse, bem, nessas novas tabelas e colunas, haverá dados reais do cliente. Ele então disse, então copie-o em uma tabela temporária, qual é o problema. Eu o encarei, incrédula: quando um cliente liga e diz: meu dinheiro desapareceu 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ê lida com o dinheiro de outras pessoas, precisa agir como um adulto responsável. Pelo que sei, ele ainda não sabe; ele não está mais conosco.
O campo MySQL ficou assim por um longo tempo; eles diriam que você não precisava de transações, chaves estrangeiras, etc., se você pensou que era, apenas porque você 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 os ORMs, como ActiveRecord ou Hibernate, foram desenvolvidos, para que eles possam escrever aplicativos de banco de dados sem precisar tocar no SQL. Uso dessas tecnologias que considero uma bandeira vermelha - essa não é uma empresa que valoriza as habilidades de DBA. O que eles realmente querem é uma babá ...