¿Cuándo debería utilizar procedimientos almacenados en lugar de simplemente escribir la lógica directamente en mi aplicación? Me gustaría aprovechar los beneficios de los procedimientos almacenados, pero también me gustaría que mi lógica de aplicación no se extienda sobre la base de datos y la aplicación.¿Cuándo debo usar los procedimientos almacenados?
¿Hay alguna regla general que se pueda imaginar en referencia a esto?
Guau ... voy a nadar directamente contra la corriente aquí y decir "casi siempre". Hay una larga lista de razones, algunas/muchas de las cuales estoy seguro que otros argumentarían. Pero he desarrollado aplicaciones con y sin el uso de procs almacenados como capa de acceso a datos, y mi experiencia es que los procedimientos almacenados bien escritos hacen que sea mucho más fácil escribir su aplicación. Luego están los beneficios de seguridad y rendimiento bien documentados.
* bien * beneficios documentados de rendimiento y seguridad. Solo quería repetir eso. No ponemos TSQL en aplicaciones, NUNCA. El SQL va en un procedimiento almacenado, el procedimiento se llama desde el código. Ningún código llega a tocar ni siquiera una declaración seleccionada. Ejecutar un SP o no es la diferencia entre el código precompilado e interpretado, ¿cuál prefieres? La respuesta a su pregunta es "SIEMPRE". – Jeremy
El elemento de rendimiento "bien documentado" no es un problema en función del motor de base de datos que está utilizando. Sin embargo, SIEMPRE debe usar procs almacenados simplemente debido a problemas de seguridad. Al usar procs, puede denegar el acceso directo a la tabla y, por lo tanto, protegerse completamente contra la mayoría de las formas de inyección destructiva de sql. De lo contrario, depende del código para detenerlo; que no todos los programadores son creados iguales. – NotMe
@ Chris Lively: las consultas parametrizadas son las más seguras contra las inyecciones de sql. Ver http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/ –
Tiendo a evitar los procedimientos almacenados. Las herramientas de depuración tienden a ser más primitivas. Los informes de errores pueden ser más difíciles (en comparación con el archivo de registro de su servidor) y, al menos para mí, parece agregar otro idioma sin ninguna ganancia real.
Existen casos en los que puede ser útil, especialmente cuando procesa grandes cantidades de datos en el servidor y, por supuesto, desencadenadores de base de datos que no se pueden hacer en el código.
Además de eso, tiendo a hacer todo en el código y trato la base de datos como un gran volcado de datos en lugar de algo en lo que ejecuto el código.
Considere Who Needs Stored Procedures, Anyways?:
Para bases de datos modernas y el mundo escenarios de uso reales, creo que un arquitectura procedimiento almacenado tiene serias desventajas y poco práctico beneficio. Los procedimientos almacenados deben ser considerados como lenguaje de ensamblaje de la base de datos: para usarlos solo en las situaciones críticas de mayor rendimiento .
y Why I do not use Stored Procedures:
Lo peor que puede hacer, y es terriblemente común en el mundo del desarrollo Microsoft, es split related functionality between sproc's and middle tier code. Grrrrrrrr. Solo hace que el código sea frágil e incrementa la sobrecarga intelectual de al comprender un sistema.
Los malos ejemplos no eliminan las ventajas cuando un método se usa correctamente. – txwikinger
Los "malos ejemplos" de un hombre son los "buenos ejemplos" de otro hombre de por qué algo es malo " – cletus
@cletus que no tiene sentido. Un ejemplo siempre es limitado y nunca prueba una generalización. – txwikinger
Básicamente cuando tiene que realizar operaciones que involucran datos que no necesitan salir de la base de datos. Por ejemplo, si desea actualizar una tabla con datos de otra, tiene poco sentido extraer los datos y luego volver a ingresar si puede hacerlo todo en una sola toma a la base de datos.
Otra situación donde puede ser aceptable utilizar procedimientos almacenados es cuando está 100% seguro de que nunca implementará su aplicación en otro proveedor de bases de datos. Si usted es una tienda de Oracle y tiene muchas aplicaciones hablando con la misma base de datos, puede tener sentido tener procedimientos almacenados para asegurarse de que todos hablen con la base de datos de manera consistente.
Las consultas de base de datos complicadas para mí tienden a terminar como procesos almacenados. Otro pensamiento a considerar es que su base de datos puede estar completamente separada y distinta de la aplicación. Supongamos que ejecuta un Oracle DB y básicamente está creando una API para que otros desarrolladores de aplicaciones de su organización puedan llamar. Puede ocultar las cosas complicadas de ellos y proporcionar un proceso almacenado en su lugar.
Un ejemplo muy sencillo:
registerUser(username, password)
podría terminar algunas consultas diferentes (compruebe si existe, crear entradas en una tabla de preferencia, etc) y es posible que desee encapsular ellos.
Por supuesto, diferentes personas tendrán diferentes perspectivas (un DBA versus un Programador).
+1 punto muy bueno, hago lo mismo incluso cuando se codifican aplicaciones de escritorio limitadas, ya que es bueno hacer que el complejo proceso de mantenimiento de la base de datos esté oculto y oculto del código de la aplicación. – Cruachan
También puede ser muy útil como una cuestión de encapsulación y en la filosofía de DRY. Por ejemplo, uso funciones almacenadas para cálculos dentro de una tabla que necesito para varias consultas dentro del código. De esta manera utilizo el mejor rendimiento así como la garantía de que el cálculo siempre se hace de la misma manera.
No lo usaría para una funcionalidad más alta o lógica debería estar en la capa de lógica de negocios de una arquitectura, pero enfocada en la capa de modelo, donde la funcionalidad está claramente enfocada en el diseño de la base de datos diseño sin romper la API a las otras capas.
Utilizamos procedimientos almacenados para todas nuestras necesidades de informes. Por lo general, pueden recuperar los datos más rápido y de una manera que el informe puede simplemente escupir directamente en lugar de tener que hacer ningún tipo de cálculos o similar.
También utilizaremos procedimientos almacenados para consultas complejas o complicadas que necesitamos hacer que serían difíciles de leer si estuvieran dentro de nuestra base de código.
he usado procedimientos almacenados en 1 de 3 escenarios:
velocidad Cuando la velocidad es de la mayor importancia, procedimientos almacenados proporcionan un excelente método
Complejidad Cuando estoy actualizando varias las tablas y la lógica del código pueden cambiar en el camino, puedo actualizar el proceso almacenado y evitar una recompilación. Los procedimientos almacenados son un excelente método de caja negra para actualizar muchos datos en un solo trazo.
Transacciones Cuando estoy trabajando una inserción, elimine o actualice eso abarca varias tablas. Envuelvo todo en una transacción. Si hay un error, es muy fácil deshacer la transacción y lanzar un error para evitar daños en los datos.
Los 2 inferiores son muy flexibles en el código. Sin embargo, los procedimientos almacenados proporcionan un método de trabajo de caja negra cuando las operaciones complejas y de nivel de transacción son importantes. De lo contrario, quédate con las operaciones de la base de datos a nivel de código
La seguridad solía ser una de las razones. Sin embargo, con LINQ y otros ORM, las operaciones DAL de nivel de código son mucho más seguras que en el pasado. Los procesos almacenados SON seguros, pero también lo son los ORM como LINQ.
Los procedimientos almacenados son un método de operaciones que se deben hacer juntos en el lado de base de datos recogida, mientras que todavía mantenerlos en el lado de base de datos.
Esto incluye:
etc.
El principal problema con procedimientos almacenados es que son difíciles de mantener.
Usted, por lo tanto, debe hacer que los procedimientos almacenados sean tan fáciles de mantener como todos los demás códigos.
Tengo un artículo sobre este tema en mi blog:
Esto depende totalmente de su entorno. La respuesta a la pregunta realmente no es un problema de codificación, ni siquiera un problema de análisis, sino una decisión comercial.
Si su base de datos admite solo una aplicación, y está razonablemente integrada con ella, entonces es mejor, por razones de flexibilidad, ubicar su lógica dentro de su programa de aplicación. En estas circunstancias, manejar la base de datos simplemente como un repositorio de datos simple que usa una funcionalidad común le pierde poco y gana flexibilidad -con proveedores, implementación, implementación y mucho más- y muchos de los argumentos puristas que la multitud de "bases de datos son para información" son demostrativamente cierto.
Por otro lado, si está manejando una base de datos corporativa, que generalmente puede identificarse por tener múltiples rutas de acceso a ella, entonces es muy recomendable reducir la seguridad lo más que pueda. Por lo menos, todas las restricciones apropiadas deberían estar habilitadas, y si es posible, el acceso a los datos debería realizarse únicamente a través de vistas y procedimientos. programadores lloriqueo debe ser ignorado en estos casos como ...
codificadores que se sumergen en guerras religiosas sobre el uso o no de los SP en general, han trabajado en un solo medio ambiente o la otra de modo que extrapolar su experiencia limitada en una posición de hierro fundido - que de hecho será perfectamente defendible y correcta en el contexto del que vienen, pero se pierde el panorama general. Como siempre, debe tomar una decisión sobre las necesidades de la empresa/clientes/usuarios y no sobre qué tipo de metodología de codificación prefiere.
He tenido algunas muy malas experiencias con esto.
No me opongo a los procedimientos almacenados en su lugar, pero el uso gratuito de procedimientos almacenados puede ser muy costoso.
Primero, los procedimientos almacenados se ejecutan en el servidor de la base de datos. Eso significa que si tiene un entorno multiservidor con 50 servidores web y un servidor de base de datos, en lugar de distribuir cargas de trabajo en más de 50 máquinas baratas, cargue uno caro (ya que el servidor de base de datos se suele construir como un servidor pesado). Y te arriesgas a crear un punto único de falla.
En segundo lugar, no es muy fácil escribir una aplicación únicamente en procedimientos almacenados, aunque me encontré con uno que hizo un esfuerzo sobrehumano para intentarlo. Así que terminas con algo que es costoso de mantener: se implementa en 2 lenguajes de programación diferentes, y el código fuente a menudo no está en un solo lugar, ya que los procedimientos almacenados se almacenan definitivamente en el DBMS y no en un archivo fuente. Asumiendo que alguien alguna vez manejó/molestó o los sacó del servidor de la base de datos y los archivó en su origen.
Así que, aparte de una arquitectura de la aplicación bastante desordenada, también se limita el conjunto de chimpancés calificados que pueden mantenerlo, ya que se requieren múltiples habilidades.
Por otro lado, los procedimientos almacenados son extremadamente útiles, SI:
Es necesario mantener algún tipo de integridad de los datos a través de múltiples sistemas. Es decir, la lógica almacenada no pertenece a ninguna aplicación, pero necesita un comportamiento constante de todas las aplicaciones participantes. Una cierta cantidad de esto es casi inevitable en las aplicaciones de hoy en día en forma de claves externas y factores desencadenantes, pero ocasionalmente, también se puede justificar una edición y validación importantes.
Necesita un rendimiento que solo se puede lograr ejecutando la lógica en el servidor de la base de datos y no como un cliente. Pero, como dije, cuando haces eso, estás consumiendo los recursos totales del sistema del servidor DBMS. Por lo tanto, le corresponde asegurarse de que si hay partes significativas de la operación ofensiva que PUEDEN descargarse en los clientes, puede separarlas y dejar las cosas más importantes para el servidor DBMS.
Si tiene "50 servidores web", espero que tenga al menos un DBA. Quien sabe TSQL. En qué se escriben los procedimientos almacenados. No hay nada desordenado al respecto: lo que es desordenado es no usar los procedimientos de la tienda. – Jeremy
Procs almacenados no tiene nada que ver con la cantidad de servidores de bases de datos que necesitará. La simple razón es que no importa si se trata de un proceso o SQL incorporado, el servidor de bases de datos aún tiene que ejecutar el código. – NotMe
"ya que los procedimientos almacenados se almacenan definitivamente en el DBMS y no en un archivo de origen". Desarrolladores incorrectos. Siempre, siempre guardamos los procedimientos almacenados en un archivo fuente. Y no tienen que ser retirados de la base de datos y puestos en el archivo fuente, ya que fluyen del archivo de origen a todas las bases de datos. (excepto cuando se están desarrollando en el desarrollador) –
Tiendo a utilizar siempre procedimientos almacenados. Personalmente, creo que hace que todo sea más fácil de mantener. Luego están las consideraciones de seguridad y rendimiento.
Solo asegúrese de escribir procedimientos almacenados limpios, bien diseñados y bien documentados.
Lo dije en un comentario, pero lo voy a volver a decir aquí.
Seguridad, Seguridad, SEGURIDAD.
Cuando el código sql está incrustado en su aplicación, debe exponer las tablas subyacentes al acceso directo. Este podría sonido bien al principio. Hasta que te golpeen con una inyección sql que codifica todos los campos varchar en tu base de datos.
Algunas personas pueden decir que lo solucionan mediante el uso de comillas mágicas o alguna otra forma de escapar correctamente de su sql incrustado. El problema, sin embargo, es la única consulta que un dev no escapó correctamente. O bien, el desarrollador que se olvidó de no permitir que se cargue el código. O bien, el servidor web que fue crackeado, lo que permitió al atacante cargar el código. O ... entiendes el punto. Es difícil cubrir todas tus bases.
Lo que quiero decir es que todas las bases de datos modernas tienen seguridad integrada. Simplemente puede denegar el acceso directo a la tabla (seleccionar, insertar, actualizar y eliminar) y forzar que todo pase por sus s'procs. Al hacerlo, los ataques genéricos ya no funcionarán. En cambio, el atacante debería tomarse el tiempo para aprender los detalles más íntimos de su sistema. Esto aumenta su "costo" en términos de tiempo pasado y deja de conducir y ataques de gusanos.
Sé que no podemos protegernos contra todo, pero si se toma el tiempo de diseñar sus aplicaciones para que el costo de descifrar supere con creces los beneficios, entonces va a reducir seriamente su potencial de pérdida de datos. Eso significa aprovechar todas las herramientas de seguridad disponibles para usted.
Finalmente, en cuanto a la idea de no usar s'procs porque es posible que tenga que portar a un rdbms diferente: Primero, la mayoría de las aplicaciones no cambian los servidores de bases de datos. En segundo lugar, en el caso de que sea una posibilidad real, debe codificar utilizando ANSI sql de todos modos; que puedes hacer en tus procs. Tercero, tendría que reevaluar todo su código sql sin importar qué y es mucho más fácil cuando ese código está en un solo lugar. En cuarto lugar, todas las bases de datos modernas ahora admiten s'procs. En quinto lugar, al usar s'proc's puede personalizar su sql para la base de datos en la que se está ejecutando para aprovechar las extensiones sql de esa base de datos en particular.
Una ventaja más, es más fácil cambiar el código sql en s'procs en una aplicación ya lanzada que redistribuir una aplicación completa debido a un cambio de consulta menor. – NotMe
Un escenario particular que probablemente beneficie implica la situación en torno al "(n + 1)" problema de escalabilidad. Cualquier tipo de situación multidimensional/jerárquica es probable que involucre este escenario.
Otro escenario implicaría casos de uso donde se realiza algún protocolo al manejar las tablas (sugerencia: pasos definidos que transacciones probablemente involucrarán), esto podría beneficiarse de la localidad de referencia: Estar en el servidor, las consultas pueden ser beneficiosas. OTOH, podría suministrar un lote de declaraciones directamente en el servidor. Especialmente cuando estás en un entorno XA y tienes que acceder a las bases de datos federadas.
Además de las consideraciones de velocidad y seguridad, tiendo a pegar tanto en los procedimientos almacenados como sea posible para facilitar el mantenimiento y las modificaciones. Si coloca la lógica en su aplicación y luego descubre que la lógica sql tiene un error o necesita trabajar de manera diferente, debe recompilar y volver a implementar la aplicación completa en muchos casos (especialmente si se trata de una aplicación del lado del cliente como WPF). , Win-Forms, etc.). Si mantiene la lógica en el proceso almacenado, todo lo que tiene que hacer es actualizar el proceso y nunca tiene que tocar la aplicación.
Si está hablando de lógica empresarial en lugar de simplemente "Debería usar sprocs en general", diría que debería poner la lógica empresarial en sprocs cuando está llevando a cabo grandes operaciones basadas en conjuntos o en cualquier otro momento ejecutando la lógica requeriría un gran cantidad de llamadas a la base de datos desde la aplicación.
También depende de su público. ¿Es importante para usted la facilidad de instalación y portabilidad en DBMS?
Si su programa debe ser fácil de instalar y fácil de ejecutar en diferentes sistemas de bases de datos, entonces debe mantenerse alejado de los procedimientos almacenados y también buscar SQL no portátil en su código.
Sí, sí, la gente siempre cita esto como la razón por la que debería evitar el SQL no estándar, pero en la práctica casi no hay razón para cambiar de proveedor de bases de datos (no creo que lo haya visto en 30 años en TI) excepto en el más trivial de los proyectos) – Cruachan
Cuando todo el código está en un proceso almacenado, es mucho más fácil refactorizar la base de datos cuando sea necesario. Los cambios en la lógica son mucho más fáciles de impulsar también. También es mucho más fácil realizar la sintonía de rendimiento y, tarde o temprano, la optimización del rendimiento se vuelve necesaria para la mayoría de las aplicaciones de bases de datos.
Estoy de acuerdo en que deben usarse con frecuencia.
El caso de uso, creo que es extremadamente convincente y extremadamente útil si está tomando mucha información en bruto que debe separarse en varias tablas, donde algunos de los datos pueden tener registros que ya existen y necesitan estar conectado por ID de clave foránea, entonces puede simplemente EXISTIR si comprueba e inserta si no lo tiene o devolver la clave si lo hace, lo que hace que todo sea más uniforme, breve y mantenible a largo plazo.
El único caso en que sugeriría contra uso es si usted está haciendo una gran cantidad de lógica o de cálculos numéricos entre las consultas que se realiza mejor en el servidor de aplicaciones o si usted está trabajando para una empresa donde mantener todo de la lógica en el código es importante para la mantenibilidad/comprensión de lo que está sucediendo. Si tienes un repositorio git lleno de todo lo que alguien necesitaría y es fácilmente comprensible, eso puede ser muy valioso.
Sugiera eliminar la etiqueta php ya que php podría ser fácilmente cualquier otro lenguaje de programación. – Iain