Cada declaración SQL debe ser revisada por un DBA: ¿común?


11

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.


2
Bueno, no ponemos declaraciones SQL en el código. Sin embargo, TODO el código debe ser revisado por personas con conocimientos apropiados
CaffGeek

44
El desarrollo web es crítico. El resultado se enfrenta directamente al cliente (quién es su rey), y la mayoría de las veces, el servidor web puede acceder a los datos confidenciales.
thiton

2
La pregunta es, si un DBA no pasa todas las consultas, ¿cómo define qué debe y qué no debe pasar el DBA?
programador

66
@thiton: Esa es una declaración general asumiendo que TODAS las aplicaciones web son públicas y son las aplicaciones más importantes de la organización. Eso simplemente no es cierto. A veces, las aplicaciones web son de tercer nivel o inferiores (en comparación con otras aplicaciones). Algunos son utilizados solo por pequeños equipos internos. Sin saber en qué está trabajando @ DanEllis, realmente no sabemos cuán crítico es este trabajo de desarrollo web.
FrustratedWithFormsDesigner

2
¿Aún no te han mordido? Considere preguntar por qué este procedimiento está en su lugar ...

Respuestas:


15

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:

  • Uso del índice: ¿la consulta estaba haciendo un análisis completo de la tabla?
  • Mantenibilidad: ¿iba a necesitar cambiar la consulta en un par de semanas porque había algo codificado en ella? ¿Y es legible la consulta?
  • Eficiencia general: ¿podría reemplazarse una unión interna por una existente? ¿Añadir un bloque con ayuda?
  • Problemas de bloqueo: ¿la consulta bloqueará la base de datos y evitará que ocurran actualizaciones? Esto sucedió más de lo que me importa pensar.

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.


-1 Una gran respuesta, pero desafortunadamente la pregunta fue sobre la revisión de un dba después de la revisión de un programador compañero. Esta respuesta es realmente a la pregunta "debería revisarse todo el código", pero esa no fue la pregunta que se hizo. No rechazo mucho ni por rencor, solo cuando responden no es una respuesta a la pregunta.
Michael Durrant

Exactamente. Este es un código que ya ha sido revisado en contexto . Eso es importante. Una consulta aislada puede parecer inocua, pero colóquela dentro de un bucle y, de repente, no lo es tanto.
Isvara

1
¿Hay alguna herramienta para automatizar este tipo de cosas? Estoy pensando en una herramienta que crea un plan de ejecución para todas las consultas enviadas y luego marca cualquier cosa con escaneos de tabla completa o producto cartesiano. Dudo que pueda atrapar todo , pero probablemente aceleraría el tiempo de revisión y también podría ser ejecutado por los desarrolladores a través de un script, o incluso mejor si se ejecuta automáticamente en el momento del check-in del código.
FrustratedWithFormsDesigner

10

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.


5

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 ...

  • Cuánto tiempo pasa un desarrollador sacando sql del código y preparándolo para enviarlo a un DBA
  • ¿Cuánto tiempo tarda el DBA en revisar el sql?
  • ¿Con qué frecuencia los cambios solicitados por el DBA? Desglosado por
    tipo de consulta ?

Hacer un seguimiento de esto solo por un tiempo probablemente muestre qué tanto arrastre es versus cuán efectivo es.


66
Estas son cosas excelentes para medir. Mientras lo hace, ¿cuánto tiempo se dedica a reparar el código roto que se permitió en la producción? ¿Cuántas horas le lleva a Ventas y Marketing encontrar clientes para reemplazar a esos clientes perdidos mientras su sitio no funciona porque una cláusula WHERE perdida causó escaneos de tabla repetidos? La revisión del código tiene costos y beneficios, no descuide tampoco.

44
Por eso es importante saber cuántas veces el DBA solicita / necesita cambios. La pregunta dice explícitamente que todo se revisa, sin excepciones. Es este tipo de política amplia que generalmente tiene más costos que beneficios. Soy un gran defensor de la revisión y prueba del código, pero eso no significa que cada línea sea revisada o probada. Se supone que somos profesionales y hay una diferencia entre el control de calidad y el cuidado de niños.
BZink

4

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.


¿Te gustaría sonar más sagrado que tú?
sevenseacat

2
@Karpie, al menos se tomó el tiempo para responder basándose en su propia experiencia, en lugar de hacer un comentario sarcástico y sin valor sobre la respuesta de otra persona como lo hizo Karpie.
Dibujó

2

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.


2

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.


1
Si bien ese es un punto de vista razonable, debe permitir que seamos muy pocos de nosotros tan inteligentes como nos gustaría pensar que somos y los peores delincuentes son los más ignorantes (casi por definición, no esos por aquí), así que evite el problema es tener una regla general - todos tratan igual
Murph

2
@Murph, absolutamente. Podría cometer un error. Pero también podría tomar descansos de baño de 2 horas todos los días. ¿Deberían todos controlar el tiempo de baño para evitar eso? ¿Deberíamos firmar formularios para obtener clips para evitar el robo de clips? En algún momento, debes confiar en las personas o despedirlas. Mi consulta lenta tiene un costo, pero también lo hace un proceso de revisión que consume mucho tiempo y que absorbe el alma. Solo si pequeñas diferencias en el rendimiento de la base de datos costarían millones (o vidas), aceptaría este tipo de cosas.
Nathan Long

1
El problema con esto es que probablemente no eres el desarrollador promedio; y muy probablemente no sea el desarrollador del problema. He trabajado en un lugar como este, y fue un poco desagradable; ¿pero sabes que? Nuestros DBA fueron los que recibieron la llamada en medio de la noche cuando se interrumpieron las consultas, no yo. Si son los responsables, tienen derecho a revisar el código del que son responsables.
Telastyn

@Telastyn: el "desarrollador no promedio" que no compro; Todavía digo que no contrates malos desarrolladores. Pero sí, si los DBA tienen que recibir la llamada, simpatizo un poco más.
Nathan Long

@NathanLong es cuestión de contexto: en los contextos en los que trabajas, presumiblemente no es un problema, en otros es evidente que tiene el potencial de serlo y una de las formas en que evitas ciertos problemas es tener lo que parecen ser reglas sin sentido (aunque , como el hecho de que siempre uso {} en mis declaraciones if, se hace con un propósito). Es malo "porque no me gusta y creo que estoy seguro, así que no debería aplicarse a mí" es un argumento cuestionable (la misma lógica se aplica para ignorar los límites de velocidad). Hmm, eso es discutidor) -: Lo siento.
Murph

2

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.


2

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.


0

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.


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.