Me refiero a todo, no solo a los cambios de esquema. Incluso un simple SELECT en una clave primaria no puede entrar en producción, a pesar de que ha sido revisado por código por otros desarrolladores (en contexto), sin una revisión DBA de cada declaración, extraída del código y enviada con la salida EXPLAIN, detalles de con qué frecuencia se llamará, etc., etc.
Si ha estado en un entorno así, ¿le pareció una ganancia neta o un obstáculo para el desarrollo? Como alguien que ha estado trabajando con bases de datos relacionales durante años, considero que la actitud de "los desarrolladores no pueden confiar en usar bases de datos" no es justificada, y tengo curiosidad sobre cuán común es esta situación. Por lo que vale, esto es solo para el desarrollo web, no es algo crítico.
fuente
Respuestas:
En uno de mis trabajos anteriores, yo (junto con otros tres programadores) fui responsable de revisar cada procedimiento almacenado creado o actualizado antes de que entrara en producción para más de 40 programadores. Como revisor fue un verdadero lastre para mi tiempo, pero en general todavía era necesario porque con eso muchos desarrolladores cometerán un error de vez en cuando. Se produjo porque teníamos programadores extraterritoriales que escribieron declaraciones SQL realmente malas (sabias eficientes) y se negaron rotundamente a aprender (ese equipo finalmente se cerró).
En general buscamos:
La mayoría de las veces, la mayoría de las consultas no tenían problemas y seguimos adelante. Pero cada revisión tomó entre 10 minutos y dos horas, dependiendo de la consulta. A una parte de mí le gustó la idea de hacer revisiones porque evitaba la temida llamada telefónica de las 2 a.m. porque algunos informes estaban causando un problema con otra aplicación. Pero al mismo tiempo, pensé que era un poco exagerado porque todos somos adultos y la persona que escribe la consulta debería hacer todo eso por sí misma.
Creo que las consultas complejas deberían ser parte de la revisión de código estándar, pero no necesitan pasar por un DBA. Tampoco es necesario revisar declaraciones simples de inserción / actualización / eliminación. Además, como redactor de una consulta, debe saber cuándo se ha vuelto demasiado complejo y saber cuándo solicitar una revisión de un DBA.
Actualización En mi primer trabajo, todas las consultas fueron escritas por DBA y eso fue un factor decisivo en el desarrollo. Tuve que enviar todas las columnas que quería, las tablas donde se ubicaban las columnas y finalmente mis criterios de búsqueda. Incluso las instrucciones básicas de inserción / actualización / eliminación necesitaban pasar por un DBA. Finalmente llegué al punto en el que podía escribir el SQL que quería, hacer que lo vieran y realizar los cambios necesarios, y luego envolver un procedimiento almacenado a su alrededor, pero eso fue solo un par de años allí. Esa compañía en particular contrató a muchos graduados universitarios recientes y de esta manera se aseguraron de que los nuevos muchachos no escribieran consultas que mataran el rendimiento.
fuente
Depende totalmente del medio ambiente, la industria y la empresa.
Algunos ejemplos:
En la NASA, múltiples niveles de verificación y revisión son el estándar. El más conocido "debería haber verificado dos veces" fue cuando se envió una sonda a Marte y Estados Unidos hizo los cálculos en pies, pero los europeos en metros. La sonda se perdió.
En una startup sin DBA (común en estos días) no habrá revisión de DBA y posiblemente ni siquiera revisión de programador (por ejemplo, si no hay otros programadores en la empresa).
En una empresa cuyo producto es un almacén de datos de cientos de millones de filas, asegurarse de que las consultas sean eficientes y correctas pueden ser cuestiones clave en el núcleo del negocio que deben verificarse.
Una empresa cuyo producto principal es un sitio web principalmente estático con un pequeño número de interacciones de bases de datos, puede considerar que la base de datos y su eficiencia son menos relevantes. Puede ser que la compañía elija gastar su "presupuesto" de revisión en las páginas estáticas que se consideran más críticas.
fuente
Nunca he trabajado en un entorno así, estoy seguro de que lo odiaría. Se me ocurre una idea para comenzar a realizar un seguimiento de algunas métricas en torno a esto ...
tipo de consulta ?
Hacer un seguimiento de esto solo por un tiempo probablemente muestre qué tanto arrastre es versus cuán efectivo es.
fuente
La mayoría de los desarrolladores son completamente ignorantes cuando se trata de bases de datos. Ni siquiera son conscientes de su ignorancia. Yo solía ser un desarrollador ignorante.
Los desarrolladores viven en un mundo de optimización es malvado. Esa mentalidad no funciona cuando realiza operaciones contra un disco. Esa mentalidad no funciona cuando elige un tipo de datos que es 8 veces más grande de lo que debe ser, lo que hace que el índice sea 8 veces más grande de lo que debe ser, por lo que ya no puede caber en la memoria. Esa mentalidad no funciona cuando programa contra una API genérica que actualiza de forma redundante todas las columnas de una tabla (no, gracias Java Beans).
No saben qué es una exploración de tabla completa. No saben cómo procesar datos en una sola operación de conjunto en lugar de abrir un cursor. Peor que un cursor, consultarán los datos, luego los procesarán fila por fila yendo y viniendo a la base de datos cuando una sola actualización simple y simple sea suficiente. Resultando en un rendimiento HORRIBLE.
No conocen los graves impactos de los informes en tablas grandes. Tal vez la necesidad de informes requerirá crear un esquema en estrella y una fuente de datos en él. Su desarrollador promedio solo consultará las tablas existentes y se preguntará por qué la consulta tarda 3 horas en ejecutarse (esta es una cifra real).
El conocimiento que tiene su desarrollador promedio será suficiente para aplicaciones CRUD "promedio" en las que un usuario simplemente edita un registro. No será suficiente una vez que salgan de la burbuja de Ruby-on-Crack y entren en el mundo real.
fuente
Depende de qué tan grande sea la base de datos y si se comparte entre múltiples aplicaciones. A menudo, al equipo de DBA le gusta saber qué consultas se ejecutarán para asegurarse de que los índices adecuados estén en su lugar, o para saber a quién notificar si tienen que dividir una tabla. Y tienden a ser un poco mejores que el desarrollador promedio al leer los planes de ejecución de consultas y detectar lugares donde se pueden especificar sugerencias para mejorar el rendimiento. También es una oportunidad para que sepan que algunas consultas de alto impacto se realizarán en la próxima versión, para que puedan recopilar diferentes estadísticas para el optimizador.
fuente
No he trabajado en un entorno así, ni lo haría.
Hay una diferencia entre el trabajo en equipo y la burocracia hostil. Como desarrollador, me encantaría recibir aportes del DBA en consultas difíciles. Pero sé cuándo pedir ayuda.
Si no soy lo suficientemente competente para
SELECTconsultas simples , debería ser despedido.fuente
He visto esto en un par de lugares diferentes. Es genial en teoría, pero rara vez he visto que sea efectivo. Este es el por qué. En primer lugar, si tiene un equipo de DBA (u otras personas), generalmente he descubierto que la persona menos competente o menos querida del grupo recibe la peor parte del trabajo de revisión. ¿Por qué dices? Es porque nadie más quiere hacerlo, y todos los demás están ocupados haciendo otras cosas que probablemente sean más urgentes. Alguna vez vi a un DBA sentarse y decir: "Hombre, todo está funcionando perfecto; puedo simplemente sentarme y navegar por la red. Ojalá tuviera algo que hacer". Yo tampoco, al menos no los buenos. Están tan ocupados u ocupados que todos los demás. Esto significa que la persona que es menos capaz probablemente esté haciendo la revisión, y esta es exactamente la persona que no desea que lo haga. El código que desea revisar es el código realmente difícil que la gente mira y lo pasa como una especie de magia negra. Los DBA junior o simplemente malos, nunca podrán captar las sutilezas de cómo funciona una consulta realmente difícil. Rara vez, como nunca, alguien dice alguna vez: "¡Hombre, no pensé en seleccionar una sola fila de una mesa usando la clave principal! Gracias DBA, eres un salvavidas". Entonces, en este escenario, realmente todo lo que está haciendo es crear mucho trabajo por poco valor. ¡No piense en seleccionar una sola fila de una tabla usando la clave primaria! Gracias DBA, eres un salvavidas ". Entonces, en este escenario, realmente todo lo que estás haciendo es crear mucho trabajo por poco valor. ¡No piense en seleccionar una sola fila de una tabla usando la clave primaria! Gracias DBA, eres un salvavidas ". Entonces, en este escenario, realmente todo lo que estás haciendo es crear mucho trabajo por poco valor.
En segundo lugar, es simplemente más trabajo para el grupo DB. Lo que probablemente va a suceder incluso si miran otras cosas es que lo echarán un vistazo rápido y se perderá algo. Son personas ocupadas, y revisar el código lleva mucho tiempo. En verdad, no es justo que se encarguen de esto, porque es una excusa para que todos los demás sean flojos y los usen como una salida, que en última instancia es lo que sucede. Algo se rompe en la producción, y el desarrollador señala rápidamente: "Bueno, el DBA lo revisó". Ahora esto es cierto todo el tiempo, no, pero es cierto parte del tiempo y, a menudo, de las personas que necesitan revisar su código realmente. Entonces, enterró al DBA con trabajo adicional y forzó a esa persona a ser responsable de los errores de otra persona, cuando esa persona probablemente no
La única forma de resolver realmente el problema es que las personas que saben cómo escribir código SQL lo escriban. ¿Deberían recibir información de los DBA de vez en cuando? Por supuesto que deberían, pero siempre he encontrado, si no tienes tiempo para hacerlo bien la primera vez, cuándo vas a encontrar tiempo para arreglarlo.
fuente
He trabajado en ese tipo de ambiente. Todos los cambios del sistema fueron revisados por pares por pares apropiados. Para mí solo significaba que tenía que planificar con anticipación y enviar mis cambios con unos días de anticipación. SQL fue a los DBA que finalmente lanzarían el SQL en producción.
Mi SQL generalmente está bien, detectaron un par de errores tontos. Al principio se siente demasiado burocrático, pero yo trabajo en finanzas. Ya viste lo que sucede (si estás en el Reino Unido) hace unos meses, cuando un banco importante aquí estropeó una actualización de rutina y arruinó todas las transacciones que conducen a millones (al menos cientos de miles) de personas que no pueden obtener a su dinero.
fuente
Incluso iría más lejos. Verificaría el código circundante y vería cómo se pasan las variables a la consulta. A menudo es para ver cómo los desarrolladores exponen su aplicación a ataques de inyección SQL debido a su falta de conocimiento básico (suposiciones falsas "esto no se puede piratear").
También los desarrolladores sin experiencia pueden arrastrar la base de datos hasta el suelo con un mal uso de ORM o una consulta que está lejos de ser óptima.
En el proyecto más reciente en el que trabajo, ningún desarrollador front-end puede acceder a la base de datos directamente. Plantean una demanda de una función que devuelva un conjunto de datos dado y los desarrolladores de back-end lo preparan para ellos. Está funcionando bastante bien, los desarrolladores front-end escriben la interfaz de usuario y procesan los datos suministrados por las funciones escritas por los desarrolladores back-end.
fuente
En nuestro equipo de desarrollo hay un sub-equipo de 4 desarrolladores de bases de datos con experiencia en la plataforma DBMS que utilizamos. Escriben todos los SQL o al menos las revisiones y realizan cambios para cumplir con sus estándares de codificación de cualquier SQL escrito por desarrolladores de .Net. Forman parte del equipo del proyecto. Los DBA de producción pertenecen a un departamento completamente diferente y su trabajo es operativo. No revisan nuestro código o esquema SQL e incluso la implementación está programada, todo lo que hacen es ejecutar el script. Lo máximo que ayudan es en el ajuste del rendimiento.
fuente