¿Cuándo debo usar procedimientos almacenados?

15

Si tengo toda mi lógica de negocios en código y uso Entity Framework, ¿en qué situaciones (si corresponde) sería mejor mover alguna lógica de negocios a un procedimiento almacenado, en lugar de mantenerla? todo en codigo?

Para ser claros, me refiero a la configuración actual (lógica de negocios en el código), no en lugar de. He visto una serie de preguntas similares que piden los pros y los contras de tener toda la lógica empresarial en los procedimientos almacenados, pero no he encontrado mucho sobre el uso de los procedimientos almacenados con moderación para la lógica de los casos perimetrales, al tiempo que mantengo el resto de la lógica empresarial. en el código.

Si marca la diferencia, estoy usando MSSQL y Entity Framework.

Estas son las situaciones en las que he usado procedimientos almacenados antes:

  • Un informe complicado que tardaba minutos en ejecutarse (esta era una página en una aplicación web). Descubrí que podía escribir SQL que era mucho más eficiente (solo tardaba unos segundos en ejecutarse) de lo que LINQ estaba proporcionando.
  • Una aplicación web necesitaba leer y escribir en unas pocas tablas en una base de datos separada que contenía una gran cantidad de otra información sensible que era irrelevante para la aplicación. En lugar de darle acceso a todo, utilicé un procedimiento almacenado que solo hace lo que se necesita y que solo devuelve información limitada. La aplicación web podría tener acceso solo a este procedimiento almacenado, sin acceso a ninguna tabla, etc.

Otras publicaciones que he visto antes de hacer esta pregunta:

pregunta Amy Barrett 17.08.2016 - 12:57
fuente

6 respuestas

8

Ya tienes un par de escenarios perfectamente buenos.

Hay muchas otras razones también. EF es realmente bueno en CRUD y en informes bastante directos. A veces, sin embargo, EF no es la herramienta perfecta. Algunas otras razones (escenarios) para considerar el uso de procedimientos almacenados en combinación con Entity Framework incluirían:

  • Tiene unidades de trabajo complejas, quizás involucrando muchas tablas, que no se pueden envolver en una transacción fácilmente usando las características de EF.
  • Su base de datos no funciona bien con EF porque no puede aprovechar la integridad referencial declarativa (restricciones de clave externa). Este suele ser un mal escenario en el que se encuentra, pero a veces hay escenarios apropiados, como las bases de datos utilizadas para los procesos ETL.
  • Debe trabajar con datos que crucen los límites del servidor con servidores vinculados.
  • Tiene escenarios de recuperación de datos muy complejos en los que se necesita SQL "simple" para garantizar un rendimiento adecuado. Por ejemplo, tiene uniones complejas que necesitan sugerencias de consulta para funcionar bien en su situación específica.
  • Su aplicación no tiene permisos CRUD completos en una tabla, pero se puede permitir que su aplicación se ejecute en un contexto de seguridad en el que su servidor confíe (identidad de la aplicación, en lugar de la identidad del usuario, por ejemplo). Esto puede surgir en situaciones en las que los DBA restringen el acceso a las tablas a los procesos almacenados porque les da un control más detallado sobre quién puede hacer qué.

Estoy seguro de que hay muchos más además de estos. La manera de determinar el mejor camino a seguir en cualquier circunstancia particular es usar un poco de sentido común y centrarse en el objetivo principal, que debe ser escribir código de alta calidad y fácil de mantener. Elija las herramientas que le den este resultado en cada caso.

    
respondido por el Joel Brown 17.08.2016 - 19:00
fuente
2

Tal vez tenga sentido, dar la vuelta a la pregunta y encontrar casos de uso donde solo los procedimientos almacenados puedan hacer, lo que usted quiere lograr. Quizás haya realmente casos de uso, donde los procedimientos almacenados se destacan.

  

Si marca la diferencia, estoy usando MSSQL y Entity Framework.

Mi conocimiento sobre EF es limitado, pero por lo que puedo ver, EF es ( simplemente ) un ORM como cualquier otro; y afortunadamente es capaz de usar raw raw .

Si tomo tus dos puntos principales:

  

Un informe complicado que tardaba minutos en ejecutarse (esta era una página en una aplicación web). Descubrí que podía escribir SQL que era mucho más eficiente (solo tardaba unos segundos en ejecutarse) de lo que LINQ estaba proporcionando.

LINQ / EF se estaba quedando corto, al hacer un informe. Y como notó, fue SQL mucho más rápido que el uso de un ORM. ¿Pero habla a favor de procedimientos almacenados o solo en contra de usar ORM para todo?

Su problema podría resolverse obviamente con SQL . Si esa consulta se almacenó y la versión controlada en su código base, según su ejemplo, al menos no hay diferencia .

  

Una aplicación web necesitaba leer y escribir en unas pocas tablas en una base de datos separada que contenía una gran cantidad de otra información confidencial que era irrelevante para la aplicación. En lugar de darle acceso a todo, utilicé un procedimiento almacenado que solo hace lo que se necesita y que solo devuelve información limitada. La aplicación web podría tener acceso solo a este procedimiento almacenado, sin acceso a ninguna tabla, etc.

Lo mismo aquí: una simple cadena de conexión y ACTUALIZAR y su problema está listo. Este problema podría resolverse incluso con un ORM : simplemente use un servicio web delante de la otra base de datos y se logrará la misma compartementalization / aislamiento .

Así que no hay nada que ver aquí.

Mirando algunos puntos que otros han hecho:

  

Tiene unidades de trabajo complejas, tal vez involucrando muchas tablas, que no se pueden envolver en una transacción fácilmente usando las características de EF.

Pero SQL puede hacer eso. No hay magia involucrada aquí.

  

Su base de datos no funciona bien con EF

Nuevamente: use EF cuando sea apropiado.

  

Debe trabajar con datos que crucen los límites del servidor con servidores vinculados

No veo cómo ayudan los procedimientos almacenados. Así que no puedo ver una ventaja de los procedimientos almacenados; pero quizás alguien arroje algo de luz sobre eso.

  

Tiene escenarios de recuperación de datos muy complejos en los que se necesita SQL "simple" para garantizar un rendimiento adecuado

Otra vez: "Límites de EF ".

  

Su aplicación no tiene permisos CRUD completos en una tabla, pero se puede permitir que su aplicación se ejecute en un contexto de seguridad en el que su servidor confía

Está bien. Voy con un tal vez .

Hasta ahora, solo se hizo un punto half a favor de los procedimientos almacenados.

Quizás hay consideraciones de rendimiento que hablan a favor de los procedimientos almacenados.

1) El almacenamiento de consultas tiene el beneficio de una llamada simple al procedimiento almacenado que encapsula la complejidad. Dado que el planificador de consultas conoce la consulta, es "más fácil" optimizar. Pero los guardados son con el planificador de consultas sofisticado actual _minimal.

Además de eso, incluso si hay un pequeño costo al usar consultas ad hoc , si sus datos están bien estructurados e indexados cuidadosamente, la base de datos es simplemente la < em> cuello de botella de su aplicación. Entonces, incluso si hay un pequeño delta, es despreciable considerando otros factores.

2) Sin embargo, se argumentó para almacenar consultas complejas en una base de datos. Hay dos cosas a considerar:

a) las consultas complejas hacen un uso masivo de la infraestructura de base de datos, lo que aumenta los tiempos de respuesta para todas las demás consultas. No puede ejecutar muchas consultas costosas en paralelo . Esto no habla de los procedimientos almacenados de pro ni de contra , sino de consultas complejas .

b) Si la consulta lleva tiempo de todos modos, ¿por qué molestarse con las pequeñas ganancias de un procedimiento almacenado?

tl;dr

Nada habla directamente contra de los procedimientos almacenados. Por lo tanto, usar procedimientos almacenados está bien, si te hace feliz.

Pero, por otro lado, no puedo imaginar un caso de uso adecuado que diga inequívocamente pro.

  

¿Cuándo debo usar procedimientos almacenados?

La respuesta correcta es: Cuando quieras . Pero hay otras opciones.

    
respondido por el Thomas Junk 17.08.2016 - 22:24
fuente
0

Para su caso específico, ya que está utilizando el marco de la entidad, se debe considerar el uso de procedimientos almacenados cuando el marco de la entidad no cumple con un requisito o inquietud.

El marco de la entidad hace un trabajo decente y el rendimiento será cercano o igual al uso de procedimientos almacenados. Escogió el marco de la entidad porque no quería preocuparse por el SQL y dejará que el marco genere el SQL por usted.

Pero puede haber un caso de ventaja donde el marco de la entidad se queda corto y no puede satisfacer sus necesidades. En este caso, uno escribiría el SQL a mano utilizando un procedimiento almacenado o una consulta parametrizada y luego usaría el marco de la entidad para llamar a ese procedimiento almacenado / declaración SQL directamente.

Por lo tanto, no movería nada a un procedimiento almacenado a menos que el marco que se está empleando no cumpla con el requisito.

Creo que lo peor que puede pasar es que uno elige usar el marco de la entidad y luego escribe todos los procedimientos almacenados. Ahora uno tiene una capa extra que no agrega valor.

    
respondido por el Jon Raynor 17.08.2016 - 18:07
fuente
0

Tener una necesidad técnica no es la opción más probable. Los programadores prefieren sus herramientas y, por lo general, se adaptan mejor para resolver sus problemas con ellos. Poner la lógica en un espacio será la excepción. Deben considerarse la deuda técnica y los futuros desarrolladores que tienen que tomarse el tiempo para trabajar con una excepción. Puede haber un aumento de rendimiento en su RDBMS en particular que es más fácil de implementar en un sproc o tal vez incluso en otro objeto de db como una vista indexada.

Habrá ocasiones en las que necesite datos de una base de datos y simplemente no podrá obtenerlos del código de su aplicación. En muchas situaciones de grandes compañías / empresas, las necesidades comerciales pueden superar el alcance del Departamento de TI. Las empresas se compran y venden y sus aplicaciones van y vienen con ellas. A las agencias reguladoras y los bancos no les importa si no puede crear su aplicación altamente escalable y bellamente codificada. Pueden dificultar la vida del negocio, por lo que debe hacerlo.

Me he encontrado con situaciones en las que las aplicaciones de terceros o las herramientas de redacción de informes no te permiten acceder a tu código. Sin código fuente abierto, sin API, sin interfaz web y sin servicios. Lo único que tienen es su propia herramienta especial de escritura de informes que solo funciona con objetos de base de datos: tablas, vistas, funciones, funciones definidas por el usuario, etc. Ponga la lógica donde sea que pueda encontrarla.

Si tiene un DBA que es muy bueno para escribir procedimientos almacenados, puede aprovechar ese talento en algunas situaciones. Es posible que desee activar una copia de seguridad desde su aplicación porque va a realizar un cambio importante en los datos, ¿por qué no usar lo que usa su dba?

Algunas solicitudes Ad hoc son más fáciles de escribir un proceso hasta que pueda obtener toda la funcionalidad de su aplicación. Lo odiamos Nos echamos atrás, pero el espectáculo debe continuar.

    
respondido por el JeffO 17.08.2016 - 18:48
fuente
0

Recomendaría encarecidamente que no se incluya ninguna lógica empresarial en un procedimiento almacenado. Sin embargo, podría haber un caso (usted enumeró dos buenos ejemplos) donde es preferible colocar la lógica de acceso de datos allí.

En términos generales, si te sientes tentado a usar SP es un signo (un olor de código) que indica que tu modelo de datos no está bien adaptado a sus necesidades.

Editar: Cuando los desarrolladores me preguntan sobre la lógica de acceso a los datos / negocios, yo digo que la lógica de negocios es sobre cómo se comportan e interactúan los datos, mientras que la lógica de acceso a los datos es sobre cómo se almacenan y recuperan los datos.

Por ejemplo: en su modelo de dominio puede tener las entidades "Estudiante" y "Profesor", ambas derivadas de "Persona". (No es preferible decir esto, solo un ejemplo). Esto se puede almacenar en una base de datos relacional como una, dos o tres tablas. La elección depende de cuántas propiedades compartan y de los requisitos de rendimiento de lectura / escritura.

En la lógica de negocios, no debería importar cómo se almacenan esas entidades. (o si residen en un RDB en absoluto). La lógica de acceso a los datos tiene que ver con cómo se almacenan físicamente.

Entonces, con respecto a la pregunta original: si un procedimiento almacenado hace que el almacenamiento y la recuperación de datos sean más eficientes (o más sólidos), tiene un caso. Si el procedimiento almacenado es simplemente para imponer una regla que sea válida independientemente de cómo se almacenen los datos, evítelo. Hace que su código esté más unido a la base de datos.

    
respondido por el Guran 17.08.2016 - 13:29
fuente
-4

Creo que hay tres problemas aquí.

  1. La lógica de negocios en SQL es mala. Incluso si se ejecuta más rápido individualmente, no se escala.

  2. Tradicionalmente, los SPROC siempre deben usarse para el acceso a todos los datos como una capa de abstracción. Permitir que un DBA introduzca cambios en el rendimiento u otros cambios de datos sin afectar las aplicaciones consumidoras.

  3. EF no juega bien con sprocs. Perderá muchas de las características "buenas" y las ganancias de productividad al alejarse de la generación dinámica de consultas de Linq.

Por lo tanto, mi consejo general sería

  • Use SPROC para todas las consultas SQL,

  • No ponga la lógica de negocios ni ningún tipo de bucles en ellos,

  • No uses EF.

respondido por el Ewan 17.08.2016 - 14:23
fuente

Lea otras preguntas en las etiquetas