我需要创建一个Audit表，用于跟踪数据库中我的表的操作（插入，更新，删除），并添加包含日期，行ID，表名等的新行细节，所以我会知道发生了什么动作以及何时发生。
所以基本上从我的理解中我需要一个触发每个表的触发器，它将跟踪插入/更新/删除以及数据库上的触发器，该触发器将跟踪新表的创建。
我的主要问题是了解如何在这些事物之间建立联系，因此在创建新表时，将为该表创建一个触发器，该触发器将跟踪操作并根据需要为Audit表添加新行。 p>
是否可以为create_table创建一个DDL触发器，并在其内部插入/更新/删除另一个触发器？
答案 0 :(得分：1)
你不希望的是什么。我强烈建议您最好考虑通过审核来实现 在业务层面 的目标。它将产生一个更简单，更实用的解决方案。
...触发将跟踪新表创建的数据库。
我无法强调这个想法是多么 可怕 。究竟谁拥有对数据库的这种不受限制的访问权限，他们可以 创建表 而无需通过代码审查和质量检查？当然，这应该是关于生产的门控路径。一旦您意识到架构更改不应该发生 ad-hoc ，那么显而易见的是，您不需要触发器（它们本质上是 被动的 ）因为架构发生变化而做某事。
即使您可以编写这样的触发器：它在元编程级别上，并不值得尝试预见所有可能的排列。
更好的选择包括：
...将为该表创建一个触发器，该触发器将根据需要跟踪操作并为Audit表添加新行。
我已经指出为什么自动执行上述 是 可怕的 。现在我更进一步指出，完成上述 也是一个坏主意。
这是一种受欢迎的做法，我肯定会从那些能够很好地区分其特定风味的人那里获得一些好处;发誓失去多少时间＆＃34;拯救＆＃34;他们。 （甚至可能声称它是一个＆＃34;业务要求＆＃34 ;;我可以向您保证，这更有可能是真实要求的错误版本。 ）
这种方法存在根本问题：
我可以从第一手经验告诉你，解释这些审计线索除了最简单的情况并不容易。浪费的时间是荒谬的：调查问题，培训其他人能够正确解释问题，编写实用程序以尝试使用这些审计跟踪减少痛苦，精心记录结果（因为信息在原始数据中不会立即显现）
如果你有任何自我保护意识，你就会听从我的建议。
（抱歉，无法抗拒。）
更好的方法是主动计划以满足审计需求。推动特定业务需求。请注意，不同的案例可能需要不同的审计技术：
重要的是，一旦您了解 真正的 业务要求，您就不会说：＆＃34;呃，让我们跟踪一切。它可能很有用。＆＃34;取而代之的是
：