0

I am looking back at Oracle (11g) development after few years for my team project and need help. We are trying to implement a POC where any add/drop column will drop and recreate a corrosponding view. View refers to a Mapping table for producing its alias names and selection of columns.

My solutions:

--1. DDL Trigger that scans for Add Column, Drop Column -> Identifies Column Names -> Updates Field_Map table -> Drops View -> Creates View with Field_Map table alias names

Challenge: Received recursive trigger error because of View creation inside DDL

--2. DDL Trigger scans for Add Column, Drop Column -> -> Updates Field Map table -> Writes identified column names, tables to Audit_DDL table -> DML trigger on Audit_DDL table fires -> Disables DDL trigger (to avoid recursion) -> Drops view -> Creates view with Field_Map table alias names

Challenge: Received recursive trigger error. I think, it is still considering whole flow as one transaction. Separating create view under DML trigger didn't help.

so, I am thinking of alternatives:

--3. Store Trigger, Tables in Schema1 and View Schema2. I am expecting, this may avoid recursion since create view will now happen on schema2 and trigger is built on schema1.

--4. Create a Stored Procedure which scans for Audit_DDL entries (from #2) for tables, columns updated. Creates views and marks checked for processed Audit_DDL entries. Hourly job now runs this procedure.

Any suggestions? Thanks in advance for helping me out!

4

1 回答 1

1

如果您想从触发器执行 DDL,则它需要是异步的。DBMS_JOB最简单的解决方案是让 DDL 触发器使用将执行您想要执行的任何 DDL的包提交作业。ALTER在提交触发事务(语句)之前,该作业不会运行。但它可能会在几秒钟后运行(取决于正在运行的其他作业数量、允许的作业数量等)。无论您是构建要在触发器中执行的 DDL 语句并将其传递给作业,还是将作业所需的信息存储在表中并传递某种键(即对象名称)并让作业组装DDL 语句是一个实现细节。

话虽如此,这似乎是一个非常糟糕的架构。如果您要添加或删除列,则应通过适当的更改控制过程。如果更改是通过更改控制进行的,那么在同一个脚本中包含对视图的更改应该很容易。依赖于视图的应用程序应该作为变更控制过程的一部分进行测试。如果更改没有通过更改控制,并且列被添加到视图中或从视图中删除,那么您在业务流程中会遇到更大的问题,并且您很可能会导致一个或多个应用程序出现奇怪的问题以及在看似模糊的时间点上的奇妙方式。

于 2013-11-14T00:36:07.453 回答