Cuándo escribir un procedimiento almacenado largo

Question

¿Hay alguna guía sobre cuándo debe y no debe escribir un complicado procedimiento almacenado de 2000+ líneas?

En mi caso específico, este procedimiento almacenado contiene muchas declaraciones if/then, case, goto y branching. Funciona mediante la construcción de consultas SQL en función de las entradas y los resultados de las consultas y utiliza la instrucción execute para ejecutar las consultas construidas. Puede ejecutar varias consultas construidas en una sola llamada y usa los resultados de esas consultas para construir otras consultas para ejecutar.

Es bastante complicado y difícil de entender. La depuración es difícil, la única forma de saber qué está pasando es hacer una llamada para ver qué está haciendo. Apenas hay un manejo o registro de excepciones. Mantenerlo es un dolor. De hecho, nadie sabe realmente lo que hace o cómo fue creado y si tuviéramos que hacer modificaciones en él tendríamos que adoptar un enfoque de "cruzar los dedos y esperar lo mejor". Pero, creo que se hizo de esta manera por razones de rendimiento.

Este procedimiento es utilizado por muchas aplicaciones. La única otra forma en que puedo pensar para hacer algo como esto es a través de un servicio web. Probablemente sería comparable en complejidad, pero mucho más fácil de entender. Sin embargo, probablemente sería varias veces más lento, ya que aún tendría que realizar varias llamadas a la base de datos para 1 solicitud.

Entonces, mi (s) pregunta (s) son, ¿cómo decidimos cuándo y cuándo no escribir largos procedimientos almacenados?

¿Hay algo que me falta o simplemente tenemos que aguantar nuestro monstruoso procedimiento almacenado?

¿Existen formas de estructurar y descomponer los procedimientos almacenados en componentes más pequeños para que sean fáciles de entender?

¿Será un procedimiento almacenado siempre más rápido que cualquier otra cosa y la elección correcta cuando necesite realizar muchas llamadas a la base de datos?

Answer 1

No estoy seguro de que sea una buena idea escribir 2000+ LOC para una sola función. Mi reacción inicial es decir que su sproc debe dividirse en funciones más pequeñas (de tabla o escalar, lo que sea apropiado) y procedimientos almacenados (para operaciones sin consulta). Sin embargo, eso podría estar moviendo el LOC en lugar de simplificar la operación real. Desafortunadamente, sin ningún código fuente publicado sería difícil dar un consejo más específico.

Answer 2

Parece que necesita cambiar la forma en que escribe y mantiene este procedimiento almacenado.

Un procedimiento almacenado se crea a partir de una consulta SQL. Tal vez pueda escribir una aplicación/script para generar el SQL para crear/actualizar su procedimiento almacenado.

Hacer esto le daría todos los beneficios de un procedimiento almacenado reutilizable (los beneficios que ya tiene), pero facilitaría el mantenimiento del procedimiento almacenado.

Al tener un procedimiento almacenado de más de 2000 líneas, básicamente se está encerrando como la única persona que puede hacer el trabajo. Esto significa que estás atrapado donde estás y no puedes avanzar (sin promoción de trabajo, sin asignación a un nuevo proyecto, etc.).

Answer 3

Si todavía tiene este problema, puede intentar ahora usar algo de CLR (Common Language Runtime Integration) que está usando algún otro lenguaje de Microsoft como C#, visual basic, entre otros para codificar su solución. Esto ayudará con la depuración y el mantenimiento de su código.