Documentar una red gigante de procedimientos almacenados interrelacionados en una base de datos MS SQL: ¿Qué herramienta o formato?

Espero que esta sea una pregunta con una respuesta más corta que "Leer un libro de 1000 páginas", pero luego, si esa es la situación real, entonces golpéenme.

No soy un DBA real, soy un desarrollador de software que se está dando cuenta de que necesitamos un DBA y, sin embargo, la tienda en la que trabajo no tiene DBA. Sin embargo, nuestro diseño de base de datos MS SQL que incluye varios procedimientos almacenados centrales es un desastre enorme. Los procedimientos almacenados son lentos, sospechamos que tienen errores, pero ni siquiera sabemos cómo se espera que funcionen, por lo que no sabemos cómo solucionarlos.

Como principio, he decidido documentar cómo se supone que debe funcionar todo, luego comenzaremos las pruebas unitarias y crearemos un conjunto de pruebas unitarias que ayuden a demostrar que los procedimientos almacenados realmente funcionan. La lógica que realizan es una parte clave de nuestra aplicación, se podría decir que son las "joyas de la corona" del producto principal de nuestra empresa, y la forma en que funciona es completamente indocumentada.

Estoy buscando la documentación técnica específica que un DBA profesional podría esperar que exista, o podría escribirse, si fuera necesario, para comprender una red gigante de procedimientos almacenados que se llaman entre sí.

1. ¿Cuál es el formato habitual para documentar un procedimiento almacenado grande? Descripción de los valores esperados para cada parámetro In (es decir, "condiciones previas", "condiciones posteriores", es decir, para los parámetros booleanos, ¿qué cambia cuando lo enciende o apaga, etc.?)

2. ¿Cómo se suele documentar? ¿Solo comentarios de SQL? ¿Herramientas externas específicas para el propósito? "Documentación" externa? No tenemos herramientas de SQL, aparte del estudio MS SQL Management, pero nos preguntamos si existe una herramienta que mejore la comprensión, la documentación y las pruebas de nuestro entorno. Tal vez esa sea una mejor manera de hacer mi pregunta; ¿Qué herramienta necesito para resolver nuestro desorden?

Nuestro objetivo es poder:

A. Use la documentación que generamos, o cualquier herramienta que agreguemos a nuestro entorno, para ayudar a comprender cómo se supone que funcionan los procedimientos, para que luego podamos crear una cobertura de prueba unitaria para los procedimientos almacenados.

B. Muestre a los desarrolladores de aplicaciones cliente cómo llamar adecuadamente a cada uno de estos complejos procedimientos almacenados.

C. La unidad prueba nuestros procedimientos almacenados.

Lo más importante de la documentación es que tiene sentido para usted. No hay una forma realmente estándar de hacer esto.

Si tiene muchos procedimientos almacenados que se conectan entre sí comenzando con un diagrama de Visio con un objeto para cada procedimiento, los enlaces entre ellos para que pueda realizar un seguimiento de cómo van las cosas de un procedimiento a otro es probablemente un buen comienzo.

La herramienta RedGate SQL Dependency Tracker puede ser útil. Puede mostrarle gráficamente qué objetos de la base de datos (SP / vistas / tablas) dependen unos de otros. Lo utilicé mientras trabajaba con algunas tablas con las que no estaba familiarizado para determinar el orden en el que deshabilitar las restricciones.

También lo ejecuté en toda la base de datos solo por diversión y fue de manera TMI. Si puede enfocarlo a áreas específicas de la base de datos que no son locamente interdependientes, puede ser útil. El árbol de dependencias tiene opciones para organizarse visualmente usando diferentes algoritmos y eso solo hace que una evaluación valga la pena.

Rastreo. Otra opción es escribir líneas de registro al inicio y al final de los procedimientos críticos almacenados. Cada fila puede incluir una fecha, un "nivel de detalle", un "contexto", "subcontexto", nombre de proceso. y recuentos de filas. Probablemente será un desastre (piense en el registro de eventos de Windows) pero quizás sea útil en algunas secciones. Si se usa un SP para hacer realmente la inserción del registro y luego se puede encender / apagar fácilmente sin mucha carga adicional (ymmv).

Nota al margen, una vez cargué la impresora con el genial papel de 11 x 17, encontré una pequeña fuente agradable y alguna sangría lógica para resumir un flujo complejo de datos / SP en ~ 5 páginas de algunos pseudo-SQL. Estoy bastante seguro de que solo terminé refiriéndome a él un par de veces y nadie más se atrevió a acercarse, ya que allí no era estándar y es difícil confiar en algo que no está integrado y puede quedar desactualizado. ¡Sin embargo, el proceso de documentación forzó una familiaridad con el código!

Paul White me convirtió en la herramienta gratuita Atlantis Schema Surf de Atlantis Interactive, que puede ser de alguna ayuda para usted.