transacción Sql - SQL Server o C#?

Question

¿Tengo razón al decir que desde una perspectiva de rendimiento, las transacciones sql son mucho mejores dentro de un procedimiento almacenado que el código?

Por el momento, utilizo la mayoría de mis transacciones en procs almacenados, pero a veces utilizo el código para rutinas más complejas, lo que obviamente mantengo al mínimo tanto como sea posible.

Es solo que había una rutina compleja que requería demasiadas "variables" que escribir la transacción sql en C# era mucho más fácil que usar SQL Server. Es una línea fina entre la legibilidad del código y el rendimiento.

¿Alguna idea?

Answer 1

El rendimiento varía; un SqlTransaction puede tener menos sobrecarga que un TransactionScope, especialmente si el TransactionScope decide que necesita enredarse con el DTC. Pero no esperaría una gran diferencia entre SqlTransaction y BEGIN TRAN, excepto por el viaje redondo adicional. Sin embargo, TransactionScope sigue siendo rápido, y es la opción más conveniente para encapsular operaciones múltiples en una transacción, ya que la transacción ambiental no necesita asociarse manualmente con el comando cada vez.

Quizás un factor mejor (y más significativo) es el isolation-level. TransactionScope se predetermina a la más alta (serializable). Los niveles de aislamiento más bajos permiten más o menos bloqueos (pero a riesgo de lecturas no repetibles, etc.). IIRC una transacción TSQL está predeterminada en uno de los niveles inferiores. Pero el nivel de aislamiento puede ajustarse para las 3 opciones.

Answer 2

La gestión de transacciones en el código (leer C#) es una opción que se debe seguir para gestionar transacciones en múltiples fuentes de datos o sistemas. Para gestionar la transacción de una única base de datos, la gestión en el extremo del servidor siempre será más simple. Pero si cree que el código podría necesitar un escenario donde se agreguen múltiples fuentes de datos en la transacción, mantenga las transacciones en el nivel del código.

Answer 3

Creo que el procedimiento de la tienda tendrá un mejor rendimiento.

Answer 4

Si quiere decir que escribe Transacciones SQL en C# y usa ADO.Net o similar para ejecutarlas, probablemente sean menos eficientes porque SQL almacenará en caché el plan de consulta para un procedimiento almacenado (que también es el caso de Entity Framework - aunque todavía no es tan rápido como proc, no creo) entonces realmente debería hacerlo al revés - procedimientos complejos en SQL para obtener los beneficios de almacenamiento en caché (si fuera así de simple ...)

Answer 5

Depende de qué aplicación.

Pero diré que en la mayoría de los casos es mejor sorprenderse de tener lógica en la base de datos. Una ventaja de tener lógica de negocio en la base de datos, es que será igual incluso si tiene una versión WinForms y una web, o lo que sea

Pero si está hablando de CLR en SQL. Lo negativo con esto, se vuelve mucho más difícil para un DBA encontrar errores o algo por el estilo. actuación.

Answer 6

Estoy a favor de TransactionScope. Según Marc, utilice un método de fábrica en su TransactionScope para soltar el nivel de aislamiento a READ COMMITTED para los usos más comunes que pueda imaginar.

Tenga en cuenta que se puede utilizar tanto las transacciones de SQL y TransactionScope - SQL BEGIN TRAN/COMMIT TRAN tendrá poco efecto sobre TransactionScope (aparte de incrementar/decrementar @@TRANCOUNT) - de esta manera si necesita llamar a la misma sproc SQL en otro lugar, por ejemplo, de una consulta adhoc que aún obtendrá el beneficio de una transacción.

El beneficio de TransactionScope IMO es que administrará el DTC si usted necesita hacer una confirmación de 2 fases (por ejemplo, varias bases de datos, colas u otras transacciones XA). Y con SQL 2005 y versiones posteriores, funciona con Lightweight Transaction Manager, por lo que no se requerirá DTC, p. si todos los accesos son para una base de datos, una conexión a la vez.