Sé que está preguntando acerca de SQL Server, pero en el mundo de Oracle (en el pasado), las tablas temporales tenían un costo muy alto, por lo que los procedimientos y desencadenantes basados en el cursor fueron más rápidos y redujeron el "costo" para el servidor. En SQL Server, los cursores solían tener un costo mucho mayor que las tablas temporales, por lo que se desaconsejaba escribir código basado en el cursor. Estoy bastante seguro de que estas discrepancias se han eliminado en la última década.
Para hacer frente a estas situaciones, la mayoría de las personas tienen una regla general para evitar poner lógica empresarial en la base de datos. Si siempre puede hacerlo de manera totalmente absoluta, entonces no habrá ninguna razón para la lógica de procedimiento ni en T-SQL ni en PL / SQL. Las bases de datos relacionales son excelentes en la lógica basada en conjuntos. La mayoría de los lenguajes de programación modernos son excelentes en lógica de procedimiento. Es mejor usar cada uno para lo que son buenos.
Algunos desencadenantes de auditoría con los que he trabajado tenían reglas bastante complicadas para lo que tenía que verificarse y dónde debían actualizarse / registrarse las cosas. Algunos fueron para mantener los sistemas de informes sincronizados con los sistemas transaccionales (no fue mi elección, pero así lo querían). Algunos fueron para un sistema de formulario . Un formulario es una lista de medicamentos, y para cada compañía de seguros, lo que cubrirán / no cubrirán, y si se recetan drug_X, qué reemplazos están cubiertos por el seguro. También era común que las diferentes pólizas grupales de la misma compañía de seguros pagaran por diferentes medicamentos.
