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 colocar la mayor parte del código en la base de datos y utilizar todas las funciones de RDBMS como procedimientos almacenados, desencadenadores, etc., que está diseñado para manejar mejor.
Quiero saber cuándo no debo usar ORM en procedimientos almacenados / activadores y viceversa.
Los ORM no se excluyen mutuamente 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 desea. Así que el problema tampoco es o.
Los ORM pueden generar un SQL inaceptable (en términos de rendimiento) y algunas veces es posible que desee anular ese SQL con un SQL creado a mano. Una de las formas de lograr esto es mediante el uso de SP.
En DotNet, no utilice procedimientos almacenados si:
Si no está familiarizado con los procedimientos almacenados (no es su caso, pero se incluye para completar).
Si no quieres introducir una capa de complejidad y versificación para tu 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 deben compararse con los ORM. Los activadores realizan funciones que es mejor que no estén en el código de la aplicación (como el registro o la sincronización de datos entre bases de datos).
Algunas personas prefieren el uso de procedimientos almacenados en lugar de SQL en el código por diferentes motivos, como la seguridad (por ejemplo, para evitar la inyección de SQL) y por su velocidad declarada. 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 basada en su caso.
ORM a menudo asume que la base de datos existe para servir al ORM. Pero, por lo general, la base de datos existe para servir a la empresa, que puede tener cientos y cientos de aplicaciones escritas en varios idiomas que la golpean.
Pero solo es un caso de "ORM frente a 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 de negocios.
Siempre que codifique la lógica de negocios, su trabajo es asegurarse de que la base de datos cambie de un estado coherente a otro estado coherente independientemente de la aplicación que realice el cambio . De modo que realmente solo tiene dos opciones prácticas: codifíquelo una vez en la base de datos o codifíquelo una vez en una capa de acceso a datos "impenetrable".
Tenga cuidado con la interfaz de línea de comandos de dbms si utiliza un DAL "impenetrable".
Consulta simple - > ORM
Consulta compleja - > Procedimiento almacenado
El disparador se debe utilizar como invariable de registro o consiste en reglas comerciales vitales, IMHO.
Los problemas de los orms:
En desacuerdo La consulta de ORM es más simple si conoce ORM mejor que usted que sabe SQL. Los resultados de ORM son 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 empresa que vende el ORM (por ejemplo, Microsoft).
Lea otras preguntas en las etiquetas rdbms orm stored-procedures