Estoy escribiendo un muy sencillo e-commerce app en asp.net, ¿necesito usar transacciones en mis procedimientos almacenados?¿Realmente necesito usar transacciones en procedimientos almacenados? [MSSQL 2005]
Leer relación/escritura es de 9: 1
Mucha gente se pregunta - ¿necesito transacciones? ¿Por qué los necesito? ¿Cuándo usarlos?
La respuesta es simple: utilícelos todo el tiempo, a menos que tenga una muy buena razón para no hacerlo (por ejemplo, no utilice transacciones atómicas para "actividades de larga ejecución" entre empresas). El valor predeterminado siempre debe ser sí. ¿Tienes dudas? - usar transacciones.
¿Por qué son beneficiosas las transacciones? Te ayudan a lidiar con bloqueos, fallas, consistencia de los datos, manejo de errores, te ayudan a escribir un código más simple, etc. Y la lista de beneficios seguirá creciendo con el tiempo.
Aquí hay más información de http://blogs.msdn.com/florinlazar/
La respuesta es: depende. No siempre necesitas seguridad en las transacciones. A veces es excesivo. Algunas veces no lo es.
Veo que, por ejemplo, cuando implementa un proceso de finalización de la compra, solo desea finalizarlo una vez que reunió todos los datos, etc. Piense en un pago, puede retroceder, ese es un ejemplo cuando necesita una transacción O tal vez cuando es sabio usarlos.
¿Necesita una transacción cuando crea una nueva cuenta de usuario? Tal vez, si está en 10 tablas (por cualquier razón), si es solo una tabla, entonces probablemente no.
También depende de lo que vendió a su cliente y quiénes son, y si lo solicitaron, etc. Pero si tomar una decisión depende de usted, entonces yo diría que elija sabiamente.
Lo fundamental es evitar una optimización prematura. Cree su aplicación, tenga en cuenta que es posible que desee volver atrás y refactorizar/optimizar más adelante cuando lo necesite. Mire un par de proyectos de código abierto y vea cómo implementaron diferentes partes de su aplicación, aprenda de eso. Verás que la mayoría de ellos no usan transacciones en absoluto, sin embargo, hay grandes tiendas en línea que los usan.
Por supuesto, depende.
Depende del trabajo que realiza el procedimiento almacenado en particular y, quizás, no tanto de la "relación de lectura/escritura" que sugiere. En general, debería considerar incluir una unidad de trabajo dentro de una transacción si es una consulta que podría verse afectada por alguna otra, al mismo tiempo que ejecuta la consulta. Si esto suena no determinista, lo es. A menudo es difícil predecir bajo qué circunstancias una determinada unidad de trabajo califica como candidato para esto.
Un buen lugar para comenzar es revisar el CRUD preciso que se realiza dentro de la unidad de trabajo, en este caso dentro de su procedimiento almacenado, y decidir si a) podría verse afectado por alguna otra operación simultánea yb) si ese otro trabajo importa para el resultado final de este trabajo que se realiza (o, incluso, viceversa). Si la respuesta es "Sí" para ambos, entonces considere envolver la unidad de trabajo dentro de una transacción.
Lo que esto sugiere es que no siempre se puede simplemente decidir si usar o no utilizar la transacción s, sino que debe aplicarlas cuando tenga sentido.Use las propiedades definidas por ACID (Atomicidad, consistencia, aislamiento y durabilidad) para ayudar a decidir cuándo podría ser el caso.
Otra cosa a tener en cuenta es que en algunas circunstancias, especialmente si el sistema debe realizar muchas operaciones en sucesión rápida, por ejemplo, una aplicación de procesamiento de transacciones de gran volumen, es posible que tenga que sopesar el costo de rendimiento relativo de la transacción. Dependiendo del tamaño de la unidad de trabajo, una confirmación (o reversión) de una transacción puede ser costosa, lo que puede tener un impacto negativo en el rendimiento de su sistema innecesariamente o, al menos, con un beneficio limitado.
Desafortunadamente, esta no es una pregunta fácil de responder con precisión: "Depende".
Recuerde que en SQL Server, todas las operaciones CRUD de sentencia única están en una transacción implícita de manera predeterminada. Solo tiene que activar transacciones explictas (BEGIN TRAN) si necesita hacer que múltiples declaraciones actúen como una unidad atómica.
usarlos si:
"utilícelos todo el tiempo, a menos que tenga una muy buena razón para no hacerlo", esto es como decirle a la gente que use cascos todo el tiempo, a menos que tengan una buena razón para no hacerlo. –
Eso supone que usar transacciones es molesto o ridículo de alguna manera, lo que no creo que sea el caso. –
Creo que @Jeff Atwood no leyó el párrafo completo antes de llegar a la conclusión de ponerse los cascos. – Codeslayer