在 SQL Server 2008 R2 中每次 table 创建时创建触发器
Create trigger upon each table creation in SQL Server 2008 R2
我需要创建一个 Audit table 来跟踪我的 table 在数据库中的操作（插入、更新、删除）并添加新行日期、行 ID、table 名称和更多详细信息，以便我知道发生了什么操作以及何时发生。
所以基本上根据我的理解，我需要每个 table 的触发器来跟踪 insert/update/delete 和数据库上的触发器来跟踪新的 table 创建。
我的主要问题是了解如何在这些事物之间建立联系，因此当创建新的 table 时，将为该 table 创建一个触发器，它将跟踪操作并添加新的根据需要为审计 table 行。
是否可以为 create_table 创建一个 DDL 触发器，并在其中创建另一个用于插入/更新/删除的触发器？
你所希望的是不可能的。我强烈建议您最好考虑一下您真正想通过审计在业务层面实现什么。它将产生一个更简单、更实用的解决方案。
首先
...trigger on the database which is going to track new table creation.
我怎么强调都不为过这个想法有多糟糕。究竟是谁可以不受限制地访问您的数据库，以至于他们可以 创建 tables 而无需通过代码审查和 QA？这当然应该在 towards 生产的门控路径上。一旦您意识到模式更改不应该发生 临时 ，很明显您不需要触发器（它们的本质是 reactive) 做某事因为架构改变了。
即使您可以编写这样的触发器：它处于元编程级别，根本不值得尝试预见所有可能的排列。
更好的选择包括：
- 需求评估和验收：这是系统中的新信息。审核要求是什么？
- 设计审查：新table；需要审核吗？
- 测试设计：如何测试审计需求？
- 代码审查：您添加了一个新的 table。需要审核吗？
- 更不用说工具提供的功能，例如：
- 源代码管理。
- Db 部署实用程序（无论是自行开发的还是第三方的）。
第二部分
... a trigger will be created for that table which is going to track the actions and add new rows for the Audit table as needed.
我已经指出为什么自动执行上述操作是糟糕。现在我要更进一步指出完全也是一个坏主意。
这是一种流行的方法，我肯定会受到一些人的批评，他们很好地划分了他们的特殊口味；盲目发誓它“节省”了他们多少时间。 （甚至可能声称它是“业务需求”；我可以向您保证，这更有可能是 真实 需求的错误陈述版本。)
这种方法存在根本问题：
- 它是被动的而不是主动的。所以它通常缺乏上下文。
- 您将很难审核被回滚的更改尝试。 （这可能是调试的噩梦，通常会违反实际业务审计要求。）
- 解释审计将是一场噩梦，因为它只是原始数据。 信息在细节中丢失。
- 由于列 added/renamed/deleted 您的审计数据失去了凝聚力。 （虽然这通常是最少的问题。）
- 这些总是作为其他更新的一部分进行更新的额外 table 会对性能造成严重破坏。
- 通常这种审计方式涉及：每次将一列添加到“基础”table，它也会添加到“审计”table。 （这最终使“审计”table 非常像架构不佳的 持久事务日志 。）
- 采用这种方法的大多数人都忽略了“基础”tables 中可空列的重要性。
我可以根据第一手经验告诉您，除了最简单的情况外，在任何情况下解释此类审计跟踪都不容易。浪费的时间是荒谬的：调查问题，培训其他人能够正确解释它们，编写实用程序以尝试减少使用这些审计跟踪的痛苦，煞费苦心地记录发现（因为原始数据中的信息不会立即显现） .
如果你有任何自我保护意识，你会听从我的建议。
做得很好
（抱歉，忍不住了。）
更好的方法是主动计划需要审核的内容。推动特定的业务需求。请注意，不同的情况可能需要不同的审核技术：
- 如果用户执行了操作 X，请记录有关该操作的详细信息以实现合法可追溯性。
- 如果用户尝试执行 Y 但被系统规则阻止，记录 B 详细信息以跟踪规则系统的完整性。
- 如果用户登录失败，为了安全起见，记录C详细信息。
- 如果系统升级，记录D详细信息，以备故障排除。
- 如果发生某些系统事件，记录E详细信息...
重要的是，一旦您了解了 真实的 业务需求，您就不会说：“呃，让我们跟踪一切。这可能会有用。”相反，你会：
- 能够为每种不同类型的审计生成更清晰、更合适、更可靠的设计。
- 能够测试它的行为是否符合要求！
- 能够在需要时更轻松地使用审计数据。
我需要创建一个 Audit table 来跟踪我的 table 在数据库中的操作（插入、更新、删除）并添加新行日期、行 ID、table 名称和更多详细信息，以便我知道发生了什么操作以及何时发生。
所以基本上根据我的理解，我需要每个 table 的触发器来跟踪 insert/update/delete 和数据库上的触发器来跟踪新的 table 创建。
我的主要问题是了解如何在这些事物之间建立联系，因此当创建新的 table 时，将为该 table 创建一个触发器，它将跟踪操作并添加新的根据需要为审计 table 行。
是否可以为 create_table 创建一个 DDL 触发器，并在其中创建另一个用于插入/更新/删除的触发器？
你所希望的是不可能的。我强烈建议您最好考虑一下您真正想通过审计在业务层面实现什么。它将产生一个更简单、更实用的解决方案。
首先
...trigger on the database which is going to track new table creation.
我怎么强调都不为过这个想法有多糟糕。究竟是谁可以不受限制地访问您的数据库，以至于他们可以 创建 tables 而无需通过代码审查和 QA？这当然应该在 towards 生产的门控路径上。一旦您意识到模式更改不应该发生 临时 ，很明显您不需要触发器（它们的本质是 reactive) 做某事因为架构改变了。
即使您可以编写这样的触发器：它处于元编程级别，根本不值得尝试预见所有可能的排列。
更好的选择包括：
- 需求评估和验收：这是系统中的新信息。审核要求是什么？
- 设计审查：新table；需要审核吗？
- 测试设计：如何测试审计需求？
- 代码审查：您添加了一个新的 table。需要审核吗？
- 更不用说工具提供的功能，例如：
- 源代码管理。
- Db 部署实用程序（无论是自行开发的还是第三方的）。
第二部分
... a trigger will be created for that table which is going to track the actions and add new rows for the Audit table as needed.
我已经指出为什么自动执行上述操作是糟糕。现在我要更进一步指出完全也是一个坏主意。
这是一种流行的方法，我肯定会受到一些人的批评，他们很好地划分了他们的特殊口味；盲目发誓它“节省”了他们多少时间。 （甚至可能声称它是“业务需求”；我可以向您保证，这更有可能是 真实 需求的错误陈述版本。)
这种方法存在根本问题：
- 它是被动的而不是主动的。所以它通常缺乏上下文。
- 您将很难审核被回滚的更改尝试。 （这可能是调试的噩梦，通常会违反实际业务审计要求。）
- 解释审计将是一场噩梦，因为它只是原始数据。 信息在细节中丢失。
- 由于列 added/renamed/deleted 您的审计数据失去了凝聚力。 （虽然这通常是最少的问题。）
- 这些总是作为其他更新的一部分进行更新的额外 table 会对性能造成严重破坏。
- 通常这种审计方式涉及：每次将一列添加到“基础”table，它也会添加到“审计”table。 （这最终使“审计”table 非常像架构不佳的 持久事务日志 。）
- 采用这种方法的大多数人都忽略了“基础”tables 中可空列的重要性。
我可以根据第一手经验告诉您，除了最简单的情况外，在任何情况下解释此类审计跟踪都不容易。浪费的时间是荒谬的：调查问题，培训其他人能够正确解释它们，编写实用程序以尝试减少使用这些审计跟踪的痛苦，煞费苦心地记录发现（因为原始数据中的信息不会立即显现） .
如果你有任何自我保护意识，你会听从我的建议。
做得很好
（抱歉，忍不住了。）
更好的方法是主动计划需要审核的内容。推动特定的业务需求。请注意，不同的情况可能需要不同的审核技术：
- 如果用户执行了操作 X，请记录有关该操作的详细信息以实现合法可追溯性。
- 如果用户尝试执行 Y 但被系统规则阻止，记录 B 详细信息以跟踪规则系统的完整性。
- 如果用户登录失败，为了安全起见，记录C详细信息。
- 如果系统升级，记录D详细信息，以备故障排除。
- 如果发生某些系统事件，记录E详细信息...
重要的是，一旦您了解了 真实的 业务需求，您就不会说：“呃，让我们跟踪一切。这可能会有用。”相反，你会：
- 能够为每种不同类型的审计生成更清晰、更合适、更可靠的设计。
- 能够测试它的行为是否符合要求！
- 能够在需要时更轻松地使用审计数据。