我的印象是生成某种共享审计或日志记录表。您显然需要TRIGGER
在每个表的基础上定义,因此对于每个声明,您都指定相关字段,例如
CREATE TRIGGER trig_ins INSERT ON mytable
REFERENCING NEW AS new
FOR EACH ROW(EXECUTE PROCEDURE sp_ins("mytable",
"field1 = " || new.field1 || " and field2 = " || new.field2, 'I'));
但它看起来和感觉有点笨拙。我不禁认为这是某种XY 问题。
更新
(以下评论“不需要where_clause
”)
好吧,显而易见的答案是确保每个表都有一个简单的单一代理键列,可以将其视为 ROWID。
当然,当您拥有现有模型时,说起来容易做起来难。如果这不可能,那么您想要的是复合键的表示形式,如果需要,以后可以对其进行解析。具体如何执行取决于您打算如何解析它:以编程方式或通过您第一次提出的预先构建的 SQL 片段。前者更可控,但不会产生“可注入”的 SQL 片段:
EXECUTE PROCEDURE sp_ins("mytable",
"<field1>" || NVL(new.field1,"") || "</field1>" ||
"<field2>" || NVL(new.field2,"") || "</field2>",
"I");
...是一种方法。可以做SQL片段的方式,只是构造很乱,如上图。例如,如果 field1 是字符串,则 SQL 已经损坏,您需要执行以下操作:
EXECUTE PROCEDURE sp_ins("mytable",
"field1 " || NVL('= "'||new.field1||'"','IS NULL') || ' AND ' ||
"field2 " || NVL('= "'||new.field2||'"','IS NULL'),
"I")
...而且您可以确定迟早您会遇到爱尔兰问题,即名称喜欢O'Malley
或Sylvester "Sly" Stallone
破坏那些嵌入的引号。没有优雅的解决方案,因为这是您尝试做的不优雅的事情。
Informix 提供了开箱即用的审计功能,以及探索逻辑日志的方式和方法。我不禁想到你最好去探索这些。