Este tipo de cosas varía enormemente de un lugar a otro. En mi sitio actual, la línea entre los desarrolladores y los DBA es muy borrosa: nosotros (los DBA) también escribimos PL / SQL y ellos (los desarrolladores) analizan los planes de consulta. Todos nos vemos como pares, simplemente con diferentes habilidades y responsabilidades. Esto es muy divertido: recientemente, la compañía se subió al carro de DevOps . La comunidad de la base de datos no entiende esto en absoluto; Siempre hemos trabajado así. No hace falta decir que somos enormemente productivos trabajando así: el nivel de base de datos es, con mucho,la parte más confiable de la pila de tecnología de la compañía, es fácil de operar (ya que tenemos las habilidades en el equipo de DBA para comprender la aplicación a un nivel profundo, y los desarrolladores tienen la exposición de DBA para comprender las operaciones 24/7/365 y cómo para estructurar sus aplicaciones para ello).
Pero sé a qué te refieres cuando hablas del desarrollador "equivocado". Es autodidacta, lo que en sí mismo es algo noble, pero en el camino ha desconfiado de cualquier tipo de instrucciones formales. Él no sabe lo que no sabe , y él se resiente cualquiera que trate de iluminarlo, lo ve como un insulto a sus habilidades de auto-aprendizaje. Aprendió el estilo imperativo de la programación, porque puedes aprenderlo sin ninguna de esas teorías sobre las que los tipos de CS siempre están parloteando (bueno, mal; todo el mundo necesita saber big-Oy partes similares de teoría). También aprendió un poco de OO, solo porque tiene que usar Java. Pero un buen profesional de bases de datos, desarrollador o DBA, debe sentirse cómodo pensando en un estilo declarativo, pensando en la teoría de conjuntos, las formas normales, incluso siendo capaz de comprender el álgebra relacional y el cálculo. Es muy, muy difícil comunicarse con estas personas, porque son activamente hostiles a cualquier cosa que pueda sacarlos de su zona de confort, que en general se limita a cómo formatear algo en una página web. Si piensan en las bases de datos, piensan que una tabla es como una clase y que una fila es como un objeto. Estos tipos literalmente simplemente harán, SELECT * FROM TABLEfiltrarán y ordenarán los resultados en su propio código. Realmente, realmente no entienden por qué una base de datos es mejor que un archivo plano (y no creen tan secretamente que cualquiera que use una base de datos relacional es un idiota).
Permítanme darles un ejemplo real: recientemente estaba hablando con uno de estos tipos sobre los problemas involucrados en la reversión de un lanzamiento de nuestro software después de que entró en producción, si un problema había pasado el control de calidad. Le expliqué que si bien podríamos revertir su aplicación (una de las muchas que acceden a la base de datos), necesitaría poder operar con la base de datos aún implementada. Me preguntó por qué, y le dije, bueno, en esas nuevas tablas y columnas, habrá datos reales de los clientes. Luego dijo, así que simplemente cópielo en una tabla temporal, cuál es el problema. Lo miré incrédulo: cuando un cliente llama y dice, mi dinero ha desaparecido de mi cuenta, ¿qué le decimos, que está bien, está en una mesa temporal? Simplemente no entendió que cuando se trata del dinero de otras personas, debe actuar como un adulto responsable. Por lo que sé, todavía no lo hace; Él ya no está con nosotros.
El campamento de MySQL estuvo así durante mucho tiempo; dirían que no necesita transacciones, claves foráneas, etc., si pensara que lo hizo fue solo porque no tenía idea de lo que estaba haciendo, etc., etc. (cuando crecieron, los agregaron en silencio). Estos son los tipos de personas para las que se desarrollaron ORM como ActiveRecord o Hibernate, para que puedan escribir aplicaciones de bases de datos sin necesidad de tocar SQL. Uso de estas tecnologías que considero una señal de alerta: esta no es una empresa que valora las habilidades de DBA. Lo que realmente quieren es una niñera ...