¿Los desencadenantes disminuyen el rendimiento? ¿Tablas insertadas y eliminadas?

Question

Supongamos que tengo procedimientos almacenados que realizan operaciones Insert/update/delete en la tabla.

Según algunos criterios, deseo realizar algunas operaciones.

¿Debo crear el disparador o realizar la operación en el procedimiento almacenado mismo?

¿Usar los disparadores disminuye el rendimiento?

hace estas dos tablas a saber insertan y eliminan existe (persistente) o se crean dinámicamente?

Si se crean dinámicamente tiene un problema de rendimiento.

Si son tablas persistentes, ¿dónde están?

también si exixts entonces ¿Puedo acceder a Insertada y Suprimido tablas en los procedimientos almacenados?

Answer 1

Rendimiento en qué? el desencadenador realizará una actualización en el DB después del evento para que el usuario de su sistema ni siquiera sepa que está sucediendo. Sucede en el fondo.

Su pregunta está redactada de una manera bastante difícil de entender.

Answer 2

Sí, una tabla con un disparador no funcionará tan bien como lo haría sin ella. La lógica dicta que hacer algo es más caro que no hacer nada.

Creo que su pregunta sería más significativa si pregunta en términos de si es más eficaz que algún otro enfoque que no haya especificado.

Al final, seleccionaría la herramienta más adecuada para el trabajo y solo me preocupará el rendimiento si hay un problema, incluso antes de que haya implementado una solución.

Las tablas insertadas y eliminadas están disponibles dentro del desencadenador, por lo que llamarlas desde procedimientos almacenados es un no-go.

Answer 3

Disminuye el rendimiento en la consulta por definición: la consulta está haciendo algo que de otro modo no iba a hacer.

La otra forma de verlo es esta: si fuera a hacer manualmente lo que sea que el gatillo está haciendo de todos modos, entonces aumentan el rendimiento al guardar un viaje de ida y vuelta.

Dé un paso más: esa ventaja desaparece si utiliza un procedimiento almacenado y se ejecuta en un servidor de ida y vuelta de todos modos.

Así que depende de cómo lo mires.

Answer 4

Será menos eficiente que hacer lo mismo en un proceso almacenado. Probablemente no, pero con todas las preguntas de rendimiento, la única forma de saber realmente es probar ambos enfoques con un conjunto de datos realista (si tiene una tabla de registro de 2.000.000, ¡no pruebe con una tabla con 100 registros!)

Dicho esto, la elección entre un desencadenante y otro método depende completamente de la necesidad de que la acción en cuestión suceda sin importar cómo se actualicen, eliminen o inserten los datos. Si se trata de una regla de negocio que siempre debe suceder sin importar nada, un desencadenador es el mejor lugar para ello o eventualmente tendrá problemas de integridad de datos. Los datos en las bases de datos se cambian con frecuencia de fuentes distintas de la GUI.

Al escribir un disparador, hay varias cosas que debe tener en cuenta. En primer lugar, el disparador se dispara una vez por cada lote, por lo tanto, si insertó un registro o 100.000 registros, el activador solo se dispara una vez. No puede suponer nunca que solo un registro se verá afectado. Tampoco puede suponer que siempre será solo un pequeño conjunto de registros. Es por eso que es crítico escribir todos los desencadenadores como si fuera a insertar, actualizar o eliminar un millón de filas. Eso significa lógica basada en conjunto y sin cursores o bucles while si es posible. No tome un proceso almacenado escrito para manejar un registro y llámelo con un cursor en un desencadenador.

Además, no envíe correos electrónicos desde un cursor, no desea detener todas las inserciones, actualizaciones o eliminaciones si el servidor de correo electrónico está caído.