¿Cuándo no usar ORM y prefiere los procedimientos almacenados?

13

Estoy usando PetaPoco micro-ORM. De hecho, es muy fácil y seguro trabajar con bases de datos utilizando herramientas ORM, pero lo único que odio es el código adicional. Solía poner la mayor parte del código en la base de datos y usar todas las características de RDBMS, como procedimientos almacenados, disparadores, etc., que está diseñado para manejar mejor.

Quiero saber cuándo no usar ORM sobre procedimientos almacenados / disparadores y viceversa.

orm rdbms stored-procedures

— RPK
fuente

66

Personalmente, mi problema con los desencadenantes (en particular, no se aplica a los procedimientos almacenados) es que intentan "adivinar" qué "acción comercial" ocurrió a partir de cómo se manipulan los datos en la base de datos. Si modifica la columna PRECIO en una tabla "ARTÍCULOS", entonces realmente no sabe por qué . ¿El usuario solo está corrigiendo un valor mal escrito? ¿Es eso una rebaja? ¿Es una oferta especial que solo dura un día? Los disparadores tienen que adivinar todo eso.

— Joachim Sauer

16

Los ORM (mapeo relacional de objetos) no son mutuamente excluyentes con los procedimientos almacenados. La mayoría de los ORM pueden utilizar procedimientos almacenados. La mayoría de los ORM generan procedimientos almacenados si así lo elige. Por lo tanto, el problema no es tampoco.

Los ORM pueden generar SQL inaceptable (en términos de rendimiento) y es posible que a veces desee anular ese SQL con SQL hecho a mano. Una de las formas de lograr esto es mediante el uso de SP (procedimientos almacenados).

En DotNet, no use procedimientos almacenados si:

Si no está familiarizado con los procedimientos almacenados (no es su caso, pero se incluye para completar).
Si no desea introducir una capa de complejidad y versificación en su proyecto.
Está creando una aplicación que debería funcionar con diferentes bases de datos o que tendría que replicarse en varios servidores de bases de datos (esta última restricción puede aplicarse solo a algunas bases de datos).

Tenga en cuenta que los desencadenantes no se pueden comparar con los ORM. Los disparadores realizan funciones que es mejor que no estén en el código de su aplicación (como el registro o la sincronización de datos en bases de datos).

Algunas personas prefieren el uso de procedimientos almacenados en lugar de SQL en el código por diferentes razones, como la seguridad (por ejemplo, para evitar la inyección de SQL) y por su velocidad reclamada. Sin embargo, esto es algo discutible y necesita una discusión detallada.

Si su ORM no puede generar Procedimientos almacenados, y tiene que escribir un sistema grande, entonces necesita ponderar la codificación manual adicional según su caso.

— Ninguna posibilidad
fuente

2

Creo que el argumento de seguridad no está relacionado con la inyección de SQL, sino más bien con los permisos (es decir, en su mayoría es sencillo administrar los permisos para un procedimiento almacenado específico para los usuarios que tienen acceso a la base de datos, sino administrar esos permisos en tablas, columnas y filas es más difícil o imposible). Aún así, el argumento de seguridad sigue siendo discutible.

— Arseni Mourzenko

@MainMa, gracias por tu comentario. Según

— tengo

2

Los procedimientos almacenados prácticamente no tienen impacto en la vulnerabilidad a los ataques de inyección SQL. Los viejos mitos mueren duro.

— Plataforma

@ Plataforma 1, gracias por tu comentario, deseo obtener más información sobre lo que piensas de esto. Mi comprensión proviene de este texto (al menos): "Puede frustrar los ataques de inyección de SQL Server utilizando procedimientos almacenados y comandos parametrizados, evitando SQL dinámico y restringiendo los permisos a todos los usuarios". que aparece en msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem sql parametrizado es un gran paso para hacerlo seguro. Creo que este tipo presenta un caso razonable palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Una búsqueda en él "Inyección de SQL de procedimiento almacenado" arrojará muchos resultados. Siempre es bueno desinfectar sus entradas y muchas plataformas proporcionan una forma integrada de hacerlo razonablemente bien.

— Rig

13

Los ORM a menudo suponen que la base de datos existe para servir el ORM. Pero, por lo general, la base de datos existe para servir a la empresa, que podría tener cientos y cientos de aplicaciones escritas en varios idiomas.

Pero es solo un caso de "ORM vs. Procedimientos almacenados" si está utilizando un ORM que no puede llamar a un procedimiento almacenado. De lo contrario, se trata de decidir dónde codificar la lógica empresarial.

Dondequiera que codifique la lógica de negocios, su trabajo es asegurarse de que la base de datos cambie de un estado consistente a otro, independientemente de la aplicación que realice el cambio . Así que realmente solo tiene dos opciones prácticas: codificarlo una vez en la base de datos o codificarlo una vez en una capa de acceso a datos "impenetrable".

Tenga cuidado con la interfaz de línea de comandos dbms si utiliza un DAL "impenetrable".

— Mike Sherrill 'Retiro del gato'
fuente

44

Me he encontrado con más de un caso en el que los SP y los activadores anteriores tenían que usarse con nuevas aplicaciones debido a las aplicaciones heredadas existentes. La ventaja es que esta lógica de negocios solo debe mantenerse en un lugar.

— jfrankcarr

Definitivamente no estoy negando que se haya usado "una base de datos para servirlos a todos", pero es sobre todo una cosa del pasado específicamente porque el mantenimiento se convierte en un verdadero infierno, especialmente cuando varias aplicaciones necesitan mantener sus propias versiones de los procesos almacenados. Tener la base de datos para servir a la aplicación que la posee es un enfoque mucho más moderno, ya que impone un acoplamiento más flexible entre aplicaciones y servicios.

— Flater

-1

Consulta simple -> ORM

Consulta compleja -> Procedimiento almacenado

— Noche oscura
fuente

3

¿Dónde se separa un complejo de una simple consulta?

— Independiente

-2

El disparador se debe utilizar como invariable de registro o constar de reglas comerciales vitales, en mi humilde opinión.

Los problemas de las ormas:

Debe establecer permisos por tablas, no por "Acción" (me refiero a SP)
Para cambiar la lógica de su solución, debe cambiar el código dentro de su aplicación y luego redistribuirlo a través de la red para los clientes

— Yuriy Vikulov
fuente

-5

Discrepar. La consulta ORM solo es más simple si conoce ORM mejor que SQL. ORM resulta en mucho más código, mucho más difícil de mantener IMO. Las únicas personas que se benefician de ORM son los accionistas de la compañía que vende el ORM (por ejemplo, Microsoft).

— fantasma
fuente

1

Es una pena que la opinión expresada en esta respuesta no esté respaldada ni por referencias ni por experiencia. Como resultado, será inútil para un lector que pueda tropezar con un reclamo "inverso", ya que los procedimientos almacenados benefician solo a los vendedores de bases de datos . Hace que uno se dé cuenta qué orientación en verdaderas preguntas tienen respuestas estados: "verdaderas preguntas tienen respuestas , no artículos o las ideas o opiniones ... "

— mosquito