在SQL Server在每次创建表创建触发器2008 R2

Question

我需要创建一个Audit表是要跟踪我的表的动作（插入，更新，删除）数据库，并与日期添加新行，行ID ，表名和一些更多的细节，所以我会知道发生了什么事情和什么时候发生。

所以基本上从我的理解，我需要它要跟踪插入/更新/删除每个表的触发器和将要跟踪新表创建数据库的触发器。

我的主要问题是了解如何连接这些东西，所以当一个新表正在创建时，将为该表创建一个触发器，该触发器将根据需要跟踪操作并为审计表添加新行。

是否有可能使一个DDL触发器create_table和它内部的另一触发插入/更新/删除？

Answer 1

你所希望的是不可能的。而且我强烈建议你最好关闭想什么你真的想在业务层面与审计实现。这将产生一个更简单，更实际的解决方案。

---

首先登场

...触发器，它是要跟踪新表创建的数据库上。

我不能强调不够这个想法如何可怕是。谁确实有这样的自由访问你的数据库，他们可以创建表没有通过代码审查和质量保证？当然这应该是门控路径朝向生产。一旦你意识到架构变化不应该发生ad-hoc，很明显你不需要触发器（这些触发器本身就是性质响应）做一些事情，因为架构改变了。

即使你能写出这样的触发器：它是在元编程水平根本不值得尝试预见到所有可能的排列的努力。

更好的选择包括：

• 需求评估验收：这是系统中的新信息。审计要求是什么？
• 设计审查：新表;它需要审计吗？
• 测试设计：如何测试审核要求？
• 代码回顾：您已添加一个新表。它需要审计吗？
• 更不用说由工具提供的如特征：
• 源控制。
• Db部署工具（无论是本土还是第三方）。

---

第二部分

...一个触发器将为该表，该表将要跟踪的行动，并根据需要为审计表添加新行创建。

我已经指出了为什么自动做上述是可怕。现在我要进一步指出，在上执行也是一个坏主意。

这是一种流行的方法，我肯定会从那些很好地划分了它的特殊风格的人那里得到一些flack;咒骂盲人多少时间“拯救”他们。 （甚至有可能出现索赔它是一个“业务需求”，我可以向你保证，更可能的真正需求的误报版本）

有这种方法的基本问题：

• 这是反应而不是主动的。所以它通常缺乏上下文。
• 您将难以审核试图回滚的更改。 （这可能是调试的噩梦，通常违反了真实的业务审计要求。）
• 解释审计将是一场噩梦，因为它只是原始数据。 信息丢失的细节。
• 由于列被添加/重命名/删除，您的审计数据失去了凝聚力。 （虽然这通常是最小的问题。）
• 这些总是作为其他更新的一部分进行更新的额外表格可能会对性能造成严重破坏。
• 通常，这种审计方式包括：每次将一列添加到“基本”表时，它也会被添加到“审计”表中。 （这最终使得“审计”表非常像一个架构不佳持久事务日志）
• 下面这个方法大多数人忽视空列在“基地”表的意义。

我可以从第一手的经验告诉你，在最简单的情况下解释这种审计线索并不容易。浪费的时间是荒谬的：调查问题，培训其他人能够正确解释它们，编写实用程序来尝试使这些审计线索的工作更轻松，刻意记录结果（因为信息在原始数据中并不显示） 。

如果你有任何自我保存意识，你会听从我的建议。

---

让它伟大

（对不起，无法抗拒。）

更好的办法是主动计划什么需要审计。推动特定的业务需求。请注意，不同的案例可能需要不同的审计技巧：

• 如果用户执行操作X，请记录A有关合法可跟踪性操作的详细信息。
• 如果用户尝试执行Y操作，但系统规则阻止它，则记录B详细信息以跟踪规则系统完整性。
• 如果用户未能登录，请出于安全目的记录C的详细信息。
• 如果系统升级，请记录D详细信息以进行故障排除。
• 如果某些系统事件发生时，记录E详细...

重要的是，一旦你知道真正业务需求，你会不会说：“呃，我们只是跟踪一切，这可能是有用的。“相反，你会：

• 能够为每种不同类型的审计生产更清洁更合适和可靠的设计。
• 能够测试它的行为按要求！
• 能够在需要时更轻松地使用审计数据。