¿Hay demasiados procedimientos almacenados?¿Puede tener demasiados procedimientos almacenados?
Sé que no hay un límite en el número que puede tener, pero ¿es este el rendimiento o la razón arquitectónica para no crear cientos, miles?
Para mí, la mayor limitación para el procedimiento de almacenamiento de cientos o miles es la capacidad de mantenimiento. A pesar de que no es un golpe de rendimiento directo, debería ser una consideración. Ese es un punto de vista arquitectónico, debe planificar no solo para el desarrollo inicial de la aplicación, sino también para futuros cambios y mantenimiento.
Dicho esto, debe diseñar/crear tantos como requiera su aplicación. Aunque con Hibernate, NHibernate, .NET LINQ trataría de mantener la lógica de los procedimientos de almacenamiento en el código, y solo ponerlo en la base de datos cuando la velocidad es un factor.
Creo que todo el tiempo que los nombra uspXXX y no spXXX la búsqueda por su nombre va a ser directa, por lo que ningún inconveniente - aunque es posible que preguntarse acerca de la generalización de los procs si tiene miles ...
Qué quiere decir además del hecho de que tienes que mantenerlos todos cuando haces un cambio en la base de datos? Esa es la gran razón para mí. Es mejor tener menos que puedan manejar muchos escenarios que cientos que solo pueden manejar uno.
Solo mencionaría que con todo esto el mantenimiento se convierte en un problema. ¿Quién sabe lo que son todos y para qué sirven? ¿Qué sucede años después cuando solo son artefactos de un sistema heredado que nadie puede recordar para qué son pero que tienen miedo de meterse?
Creo que lo principal es la pregunta de si no es posible, pero debería hacerse. Eso es solo un pensamiento de todos modos.
Como han dicho otros, realmente se trata del aspecto de gestión. Después de un tiempo, se convierte en encontrar la aguja proverbial en el pajar. Eso es aún más cuando hay estándares de nomenclatura pobres en su lugar ...
Mi pregunta es por qué no está utilizando algún tipo de plataforma de middleware si está hablando de cientos o miles de procedimientos almacenados?
Llámame anticuado pero pensé que la base de datos solo debería contener los datos y el programa (s) debería ser el que tome las decisiones de la lógica de negocios.
Eso no es exactamente cierto. Hay muchas cosas que se pueden descargar a la base de datos que en realidad están mejor hechas allí. Algunas cosas obvias podrían ser verificaciones de restricciones de nivel superior (algo que debe ser cierto sin importar cuántas aplicaciones accedan a las tablas). –
Ojalá pudiera enviar comentarios :) – Constantin
No, no que yo sepa. Sin embargo, debes tener una buena convención de nombres para ellos. Por ejemplo, comenzar con usp_ es algo que a mucha gente le gusta hacer (más rápido que comenzar con sp_).
Quizás sus informes de sprocs deben ser usp_reporting_, y sus objetos de negocio deben ser usp_bussiness_, etc. Siempre que pueda gestionarlos, no debería haber problemas con muchos de ellos.
Si crecen demasiado, es posible que desee dividir la base de datos en varias bases de datos. Esto podría tener más sentido lógico y puede ayudar con el tamaño de la base de datos y tal.
Si tiene muchos procedimientos almacenados, encontrará que se está vinculando a una sola base de datos, algunos de los cuales pueden no transferirse fácilmente.
Atarse a una base de datos no es un buen diseño.
Además, si tiene lógica comercial en la base de datos y en una capa comercial, entonces el mantenimiento se convierte en un problema.
en la base de datos Oracle, puede usar Paquetes para agrupar los procedimientos relacionados.
algunos de esos y su espacio de nombres se liberarían.
Infierno sí, puede tener demasiados. Trabajé en un sistema hace un par de años que tenía algo así como 10.000 procs. Fue una locura. Las personas que escribieron el sistema realmente no sabían cómo programar, pero sabían cómo corregir los procesos mal estructurados, por lo que pusieron casi toda la lógica de la aplicación en los procesos. Algunos de los procs corrieron por miles de líneas. Manejar el desastre fue una pesadilla.
Demasiados (y no puedo dibujar una línea específica en la arena) es probablemente un indicador de diseño deficiente. Además, como han señalado otros, hay mejores formas de lograr una interfaz de base de datos granular sin recurrir a cantidades masivas de procs.
Tengo poco menos de 200 en un producto comercial SQL Server 2005, que probablemente aumente en aproximadamente 10-20 en los próximos días para algunos informes nuevos.
Siempre que sea posible, escribo sprocs 'subrutinas', de modo que cada vez que me encuentro poniendo 3 o 4 declaraciones idénticas juntas en más de un par de sprocs, es hora de convertir esas pocas declaraciones en una subrutina, si ves lo que media.
No suelo utilizar los sprocs para realizar toda la lógica de negocios como tal, prefiero tener sprocs haciendo cualquier cosa que pueda verse como 'transaccional' - entonces dónde está mi código de cliente (en Delphi pero lo que sea) podría hacer una inserción extraña o actualizarse a sí mismo, tan pronto como algo requiere que un par de cosas se actualicen o se inserten 'a la vez', es hora de un cambio.
tengo una convención de nomenclatura sencilla, el crudo para ayudar en la lectura (y en el mantenimiento!)
nombre de código del producto es 'Rachel', por lo que tenemos
RP_whatever - these are general sprocs that update/insert data,
- or return small result sets
RXP_whatever - these are subroutine sprocs that server as 'functions'
- or workers to the RP_ type procs
REP_whatever - these are sprocs that simply act as glorified views almost
- they don't alter data, they return potentially complex result sets
- for reporting purposes, etc
XX_whatever - these are internal test/development/maintenance sprocs
- that the client application (or the local dba) would not normally use
la denominación es arbitraria , es solo para ayudar a distinguir el prefijo sp_ que usa SQL Server.
Supongo que si encontré que tenía 400-500 sprocs en la base de datos, podría preocuparme, pero unos pocos cientos no son un problema en absoluto, siempre que tenga un sistema para identificar qué tipo de actividad es cada sproc responsable de. Prefiero buscar cambios de esquema en unos cientos de sprocs (donde las herramientas de SQL Server pueden ayudarlo a encontrar dependencias, etc.) que tratar de buscar cambios de esquema en mi lenguaje de programación de alto nivel.
Sí, puedes.
demasiado de cualquier cosa en particular, probablemente significa que estás haciendo mal. Demasiados archivos de configuración, demasiados botones en la pantalla ...
No se puede hablar de otros RDBMS, pero una aplicación de Oracle que use PL/SQL debería combinar lógicamente procedimientos y funciones en paquetes para evitar invalidaciones en cascada y administrar el código mejor.
Sí, puede tener demasiados procedimientos almacenados.
Convenciones de nomenclatura realmente pueden ayudar con esto.Por ejemplo, si tiene una convención de nombres donde siempre tiene el nombre de la tabla y InsUpd o Get, es bastante fácil encontrar el procedimiento right almacenado cuando lo necesite. Si no tiene algún tipo de convención de nomenclatura estándar, sería muy fácil encontrar dos (o más) procedimientos que hagan casi exactamente lo mismo.
Sería fácil encontrar un par de lo siguiente sin tener una convención de nomenclatura estándar ... usp_GetCustomersOrder, CustomerOrderGet_sp, GetOrdersByCustomer_sp, spOrderDetailFetch, GetCustOrderInfo, etc.
Otra cosa que comienza a suceder cuando se tiene una gran cantidad de procedimientos almacenados es que tendrá algunos procedimientos almacenados que nunca se utilizan y otros que raramente se utilizan ... Si no tiene alguna forma de rastrear el uso de procedimientos almacenados, terminará con una gran cantidad de elementos no utilizados procedimientos ... o peor, deshacerse de uno que cree que nunca se usa y descubrir luego que solo se usa una vez al año o una vez por trimestre. :(
Jeff
usted tiene que poner todo ese código en alguna parte.
Si usted va a tener procedimientos almacenados en absoluto (que personalmente no favorecer a ellos, pero muchos no lo hacen), entonces puede ser que también utilizarlos como todo lo que necesita. por lo menos toda la lógica de la base de datos está en un solo lugar. la desventaja es que no es típicamente mucho la estructura de un cubo lleno de procedimientos almacenados.
su llamada! :)
Pero si generas dinámicamente parte del código, ¡no tienes tanto para poner! – MattMcKnight
No mientras tenga una convención de nombres correcta, documentación actualizada y suficientes pruebas de unidad para mantenerlos organizados.
Supongo que la pregunta más profunda aquí es: ¿en qué otro lugar debería ir todo ese código? Las vistas se pueden usar para proporcionar un acceso conveniente a los datos a través de SQL estándar. Se pueden usar lenguajes de aplicación y bibliotecas más potentes para generar SQL. Los procedimientos almacenados tienden a oscurecer la naturaleza de los datos e introducen una capa innecesaria de abstracción, complejidad y mantenimiento en un sistema.
Dado el poder de las herramientas de mapeo relacional de objetos para generar SQL básico, cualquier sistema que dependa demasiado de los procedimientos almacenados será menos eficiente de desarrollar. Con ORM, simplemente hay mucho menos código para escribir.
Mi primer gran proyecto fue desarrollado con Object Relational Mapper que abstraía la base de datos así que hacíamos todo orientado a objetos y era más fácil de mantener y corregir errores y era especialmente fácil hacer cambios desde el acceso a los datos y la lógica de negocios Sin embargo, cuando se trataba de hacer cosas complejas, el sistema se sentía lento, por lo que tuvimos que resolver esas cuestiones o volver a diseñar el proyecto, especialmente cuando el ORM tenía que realizar uniones complejas en la base de datos.
Ahora estoy trabajando en una empresa diferente que tiene el lema de "nuestras aplicaciones son solo frontends de la base de datos" y tiene sus ventajas y desventajas. Tenemos aplicaciones realmente rápidas ya que todas las operaciones de datos se realizan en procedimientos almacenados, esto es principalmente el uso de SQL Server 2005, pero cuando se trata de hacer un cambio o una solución al software es más difícil porque hay que cambiar ambos, el código C# y los procedimientos SQL almacenados por lo que es como trabajar dos veces, al contrario que cuando usé un ORM, no tiene objetos refactorizados o fuertemente tipados en sql, Management Studio y otras herramientas ayudan mucho, pero normalmente pasa más tiempo yendo de esta manera .
Así que yo diría que dependiendo de las necesidades del proyecto, si no va a mantener datos comerciales realmente complejos, tal vez incluso podría evitar el uso de procedimientos almacenados y usar un ORM que facilite la vida del desarrollador.Si está preocupado por el rendimiento y necesita guardar todos los recursos de lo que debería usar los procedimientos almacenados, por supuesto, la cantidad depende de la arquitectura que diseña, por ejemplo, si siempre ha almacenado procedimientos para operaciones CRUD, necesitaría uno para inserciones, una para actualización, una para eliminación, una para seleccionar y otra para listar ya que estas son las operaciones más comunes, si tiene 100 objetos comerciales, multiplique estos 4 por eso y obtendrá 400 procedimientos almacenados solo para administrar los más básicos operaciones en sus objetos entonces, sí, podrían ser demasiados.
Para mí, utilizar muchos procedimientos almacenados parece conducirlo hacia algo equivalente a la API de PHP. Miles de funciones globales que pueden no tener nada que ver entre sí, todas juntas. La única forma de relacionarse entre ellos es tener alguna convención de nombres donde prefija cada función con un nombre de módulo, similar a las funciones mysql_ en PHP. Creo que esto es muy difícil de mantener y muy difícil de mantener todo consistente. Creo que los procedimientos almacenados funcionan bien para las cosas que realmente necesitan tener lugar en el servidor. Un procedimiento almacenado para una consulta de selección simple, o incluso una consulta de selección con una combinación, probablemente llegue muy lejos. Solo use procedimientos almacenados donde realmente requiera que se maneje una lógica avanzada en el servidor de la base de datos.
Totalmente de acuerdo: el mantenimiento de miles de SP se vuelve poco manejable cuando ocurren cambios en el esquema. – stephbu
En segundo lugar este pensamiento, odiaría tener miles de procedimientos de tienda. –
¿No existe el riesgo de terminar con nudos de lógica de negocios en sus procedimientos almacenados o código de "spaghetti" difícil de mantener si tiene algunos sprocs multipropósito? Los procedimientos almacenados específicos que cada uno realiza una sola tarea son mucho más fáciles de mantener. – Rob