2009-04-03 9 views
8

Cuando mi aplicación C# .net actualiza los registros en más de una tabla, utilizo las transacciones, de modo que si algo falla durante la transacción, puedo deshacerlo.¿Dónde está el mejor lugar para manejar transacciones en procedimientos almacenados o en la aplicación?

¿Cuál es una mejor práctica?

-Utiliza el procedimiento almacenado con BEGIN TRANSACTION/ROLLBACK/COMMIT TRANSACTION; -Utilizar TransactionScope en la aplicación de la siguiente manera:

 

    using (TransactionScope ts = new TransactionScope()) 
    { 
    } 
 

Respuesta

4

Esto no es un problema de lógica de negocios, es un problema de integridad de datos y creo que está bien hacerlo en el procedimiento almacenado. Me gusta mantener la lógica de transacciones lo más cerca posible de las operaciones para acortar su duración.

+0

Dijo que su aplicación actualiza los registros en más de una tabla. Eso significa que o bien necesita abrir el tran en un proceso y comprometer en otro, o necesita tener toda la lógica en un proceso (o en múltiples procutos llamarse entre sí) lo que nunca es algo bueno ... – zvolkov

+0

Es cierto, la transacción db debe terminar lo más rápido posible. Lo opuesto nunca es algo bueno. – Constantin

+0

Puede tener una transacción abierta entre varias tablas, múltiples bases de datos e incluso servidores. Como dice Mufaka, lo mejor es dejar que el servidor sql maneje sus propias transacciones o podrías tener algunos problemas serios de integridad de datos. Prácticamente el punto de las transacciones, creo. – Praesagus

3

TransactionScope es una muy buena manera de gestionar las transacciones en el código. Le permite jerarquizar el código transaccionado a través de múltiples métodos y escalar automáticamente al modo distribuido, si es necesario.

Prefiero usar TransactionScope sobre las transacciones de proc almacenadas, porque le da mucho más control en el código.

1

Si su transacción va a una base de datos, entonces es mejor hacer la transacción en el procedimiento almacenado. La otra manera puede ser causada solo por un problema de logística (no le agrado al DBA o está de vacaciones). Si llama a diferentes orígenes transaccionados (SQL Server y Oracle) en una transacción, entonces no hay más opción que hacer transacciones en el código.

1

Recomiendo encarecidamente configurar un procedimiento para una página y administrar todas las acciones sql allí. Si hay varias tareas para realizar en la página que requieren múltiples procedimientos, simplemente haga que un procedimiento administre los otros procedimientos. Su procedimiento siempre puede devolver múltiples conjuntos de registros si es necesario.

  • página que llevará a cabo más rápido - no gran cantidad de datos que van y vienen, un solo tirón. Todo el código en el sql ya está compilado con los planes de ejecución.
  • Usted será capaz de resuelva sus errores mucho más eficiente - en un solo lugar en lugar en dos lugares - que tiene dos sistemas separados para decidir si es suficiente cirtical a fallar - que pasa ningún errores de ida y vuelta para mantener su integridad de datos.
  • Minimiza sus puntos de falla. Si la transacción va bien, pero el servidor web tiene problemas, el servidor sql se queda esperando una respuesta .
  • Ahorrará toneladas de solución de problemas y depuración de tiempo.
  • Te ayudará a modularizar tu código en el servidor sql. Puede reutilizar sprocs para realizar tareas similares y terminar con un sistema robusto escalable más flexible. HTH
1

Éstos son mis 2 reglas simples para cuándo utilizar transacciones:

  • si el procedimiento tiene más de un cambio de los datos de la declaración, que contendrá una transacción.
  • si la aplicación llama a más de un procedimiento almacenado que cambia los datos, contendrá una transacción.
Cuestiones relacionadas