2011-01-19 20 views
7

Actualmente estoy considerando opciones de diseño para una aplicación de informes basada en un conjunto de datos existente.Reutilización del código del servidor SQL a través de procedimientos almacenados: ¿buena o mala práctica?

Existen varias oportunidades claras para la reutilización del código dado que muchos de los informes necesitan utilizar el mismo conjunto de datos base (Editado).

La tentación es crear un procedimiento almacenado básico que pueda reutilizar a través de este sistema, sin embargo, el contrato que tenía hace 6 meses me mostró el lado negativo de esta práctica - múltiples capas de - procedimiento almacenado grande llamadas devolviendo subconjuntos de datos, lo que hace que sea muy difícil entrenar lo que estaba pasando, depurar y probar.

En estos días soy de la opinión de que la reutilización de código no mejora necesariamente el mantenimiento en el diseño de la base de datos.

Estoy buscando información sobre esto de un desarrollador de SQL Server más experimentado que yo?

Gracias de antemano.

+0

"En estos días soy de la opinión de que la reutilización del código no mejora necesariamente el mantenimiento en el diseño de la base de datos". es la pregunta principal, el resto del texto es para el contexto. – gb2d

+0

¿Hay alguna razón para la limitación específica en el título de los procedimientos almacenados? Estos no son el único mecanismo para la reutilización de código. –

+0

No realmente. Entiendo que hay varias formas de lograr la reutilización del código. – gb2d

Respuesta

9

Descargo de responsabilidad: Esto no es un "no use procedimientos almacenados - ¡piense en los niños!" publicar, y no pretendo encender una guerra de llamas. Solo sugiero que la reutilización de código es más fácil y posiblemente más adecuada para ciertas situaciones y plataformas que otras.

Código La reutilización como concepto generalmente mejora una base de código. Mantiene las cosas DRY y comienza a formar una capa de funcionalidad común para resolver problemas comunes de la misma manera.

Sin embargo, como todo, uno puede equivocarse (con el poder viene la responsabilidad, bla, bla, bla).

Es relativamente simple en la mayoría de los lenguajes de programación modernos reutilizar el código, ya sea escribiendo funciones o incluso creando marcos completos que se pueden usar una y otra vez. Sin embargo, en T-SQL es truculento porque tienes menos opciones. Los procedimientos almacenados pueden hacerlo, pero ya has visto cuán incómodos pueden ser.

Mi preferencia personal es mantener la lógica comercial fuera de la base de datos. Eso significa que no uso vistas, UDF, sprocs, etc. (a menos que después de la creación de perfiles de rendimiento pensemos que podemos acelerar algo usando estas técnicas) y en cambio lo mantengo en el código de mi aplicación. Esto a menudo causa pensamientos de una "capa de lógica de negocios", pero hay varios sabores de eso, por lo que es probablemente un nombre inapropiado. Ciertamente, no es código directamente detrás de los manejadores de clic de UI y demás.

Mi objetivo es limitar la base de datos a almacenar y recuperar datos, porque eso es lo que realmente les sirve. Todos sabemos cuán torpe y obsoleto T-SQL puede ser como un lenguaje (piense en manejo de excepciones, implementación, cursores, etc.). Ser independiente de la base de datos es completamente imposible si su aplicación está escrita en la base de datos, y tampoco puede escalar su aplicación, porque la base de datos es la aplicación. Si tiene esa lógica empresarial en el código de la aplicación, puede ampliarse mucho más fácilmente.

En este caso, la "lógica comercial" son las consultas y transformaciones utilizadas para generar sus informes, y yo investigaría cómo sería posible reutilizar el código en su herramienta/código de informe, antes de considerar otras opciones.

+0

Estoy de acuerdo con todo lo que dice. Suena como si prefiriera sql en línea sobre procedimientos almacenados? El rendimiento sufriría demasiado en mi caso por esto. Además, estoy especialmente de acuerdo con mantener la lógica de negocios fuera de una base de datos, sin embargo, la compensación aquí es que las transformaciones en la capa de lógica de negocios no son tan eficientes y pueden requerir múltiples viajes redondos a la base de datos. Esto significa que inevitablemente la lógica empresarial termina en la base de datos en mis aplicaciones. También creo que las bases de datos son excelentes lugares para hacer cumplir las reglas comerciales a través de restricciones. – gb2d

+0

No estoy entrando en un argumento de "sprocs no son mucho más rápidos" aquí, pero sí sugiero que mida el rendimiento de ambos antes de asumirlo. Érase una vez que era cierto, pero como profesión necesitamos cuestionar esas suposiciones antiguas. Los optimizadores de consultas y el almacenamiento en caché de planes de consulta en los últimos años prácticamente niegan cualquier beneficio de las consultas compiladas/sprocs. Es poco probable que las transformaciones sean mucho más rápidas, ya que puede arruinar la capacidad del motor de la base de datos para planificar de manera eficiente. Además, las restricciones no son reglas comerciales, sino reglas de integridad de datos. –

+0

I.e. es un caballo para los cursos, solo asegúrese de haber medido y probado su enfoque en lugar de hacer suposiciones. Para todos los que puedan demostrar lo que dije antes, habrá alguien que no está de acuerdo y también puede demostrarlo. Necesita * demostrar * estas suposiciones y sacar sus propias conclusiones para su situación y requisitos particulares. –

1

El objetivo principal de la reutilización de código, IMO, es dividir los programas monolíticos en piezas de fácil comprensión y mantenimiento. La división del trabajo no debe ser idiosincrásica: la idea peculiar del orden de un hombre.El arte de construir una biblioteca de funciones auxiliares es en gran parte un arte social: debe definir una API inteligible que sea coherente en su enfoque. No querrás que los codificadores que te siguen te maldigan en ausencia. Desea que le estén agradeciendo la claridad y la utilidad de su diseño.

@Neil Barnwell: No veo ningún problema con la creación de reglas de negocio en la base de datos. Los desencadenadores y los procesos almacenados pueden realizar este rol tan bien o mejor que un nivel medio o un código de cliente. Por supuesto, debe tener programadores que hayan dominado el lenguaje de programación en la base de datos, T-SQL o PL/SQL o lo que sea que sea.

+0

He visto y hecho ambas cosas, y sé que para cualquier aplicación empresarial profesional de un tamaño razonable, siempre ha sido un gran error más adelante. Hay muchas razones por las que no voy a enumerarlas aquí. Es una guerra religiosa, lo que significa, por definición, que nunca se puede ganar. Mientras no haya suposiciones, y se obtengan conclusiones científicas de observaciones reales, entonces uno debería hacer lo correcto dadas las circunstancias. –

+0

Tal vez podría considerar ser un poco más conservador con comentarios como "Los desencadenadores y los procesos almacenados pueden desempeñar esta función igual de bien ** o incluso mejor ** que un nivel medio o un código de cliente" (énfasis mío). Está comparando favorablemente el T-SQL arcaico con los lenguajes modernos y más potentes, como Java o C#, que es muy difícil de probar. –

+0

@Neil. Dije que hacer cumplir las reglas en el DB puede ser tan bueno o mejor que hacerlo en otro nivel. Usted dice que hacer cumplir las reglas en la base de datos es un "error masivo" y luego me dice que * I * debería ser más conservador en mis declaraciones. T-SQL y PL/SQL se han integrado estrechamente con operaciones de conjunto durante décadas. Los lenguajes de OO han estado jugando catchup en este particular respecto. Uso C# todo el tiempo y me encanta; ciertamente no hacer panorámicas de OO. Solo digo que puede ser excesivo aplicar las reglas de negocio cuando la mera lógica condicional y un ciclo usualmente son suficientes. – Tim

2

La reutilización de código en TSQL debe tomarse caso por caso. Debe adquirir el hábito de verificar los planes de ejecución de todas las consultas que escribe para determinar si el plan parece razonable o no.

Unir vistas a Vistas puede funcionar bien o puede causar ineficiencias según su definición.

Tabla en línea Las funciones pueden ser una muy buena manera de reutilizar el código. Evitan posibles problemas de predicado con Views y, a medida que el optimizador de consultas los expande, le permiten aplicar filtros a los resultados de manera más eficiente que intentar hacer lo mismo con un TVF de varias sentencias o un conjunto de resultados de procedimientos almacenados.

Cuestiones relacionadas