trigger, job en oracle ¿que elegir?

Yo podría un campo auto tipo date-time y que el valor por defecto sea now; eso podría ahorrarte el trigger.

Te recomiendo usar store_procedures para hacer estas pegas porque es mas facil para el desarrollador del lado http manejar su logica, mientras tu manejas la logica de la DB, y allí haces todas las comprobaciones/validaciones/arreglines y demases que requieras en el modelo de la DB.

Cosme dijo:

Yo podría un campo auto tipo date-time y que el valor por defecto sea now; eso podría ahorrarte el trigger.

Te recomiendo usar store_procedures para hacer estas pegas porque es mas facil para el desarrollador del lado http manejar su logica, mientras tu manejas la logica de la DB, y allí haces todas las comprobaciones/validaciones/arreglines y demases que requieras en el modelo de la DB.

Haz clic para expandir...

El trigger incorpora lógica plsql de stored procedured.

La mano es trigger, @Koji Nanjo . Tal como lo mencionas, puedes crear una segunda tabla de auditoría que se alimente del trigger. El trigger va asociado a la tabla en cuestión y puedes definirle que se active al insert, delete y update, y que te guarde los datos originales antes del cambio (en el caso de delete y update) y un campo de tipo fecha que almacene automáticamente la hora del sistema. De esa manera, esa auditoría es transparente a la aplicación.

Otra opción es habilitar la auditoría de oracle. Esto implica que el DBA deba activar los parámetros para que la auditoría sea precisa a una tabla en particular, y todos los registros de auditoría se almacenan en una tabla de sistema (SYS.AUD$).

Si propones trigger no va a faltar el dba alumbrado que diga que "es mejor la auditoría de Oracle porque bla-bla-bla".
Si propones auditoría de Oracle, el dba puede alegar que le estás cargando pega encima, que va a tener que administrar la huea, etc, etc.

La ventaja que tiene el trigger sobre la tabla es que como se basa en un procedimiento almacenado puedes meterle un poco de inteligencia y además el código queda del lado del equipo de desarrollo.

dale, me quedo con el trigger (además ya lo hice :X) ahora voy a hacer que gatille un procedure para que lance el dato por http.

gracias a todos

Koji Nanjo dijo:

dale, me quedo con el trigger (además ya lo hice :X) ahora voy a hacer que gatille un procedure para que lance el dato por http.

gracias a todos

Haz clic para expandir...

El mismo trigger puede llevar la lógica programada dentro con plsql. En el transantiago lo hacíamos así

Zuljin dijo:

El mismo trigger puede llevar la lógica programada dentro con plsql. En el transantiago lo hacíamos así

Haz clic para expandir...

En el transantiago... Estuvo en Sonda de casualidad?

Enviado desde mi MotoE2 mediante Tapatalk

VittokoX dijo:

En el transantiago... Estuvo en Sonda de casualidad?

Enviado desde mi MotoE2 mediante Tapatalk

Haz clic para expandir...

No, estuve en una de las empresas subcontratadas por Sonda para la operación.

Zuljin dijo:

El mismo trigger puede llevar la lógica programada dentro con plsql. En el transantiago lo hacíamos así

Haz clic para expandir...

Buena. que buenos tiempos esos de transantiago... NOT

Ojo, considera lo siguiente. Triggers con mucha lógica de negocio están propensos a gatillar errores, ya sea por reglas de negocio o por mala programación. Si tienes sistemas interactuando con estas tablas, esos errores pueden ser propagados a los usuarios, no estando relacionados necesariamente a sus sistemas. En esos casos, yo prefiero encapsular el procesamiento, posibles errores, en un stored procedure y programarlo en un job.

Saludos.


Enviado desde mi HUAWEI MT7-L09 mediante Tapatalk