1

我的问题主要是关于“什么对性能最好”，但也有点“哲学上”（如果它有所作为的话）......所以让我们直接进入。

[TableA].[ColumnB] 存储了一个需要存在于 [TableC].[ColumnD] 中的值。马上，没有涉及外键的答案- 只是假设它们在这个环境中是“不允许的”，无论出于何种原因。

但是由于“情况 x,y,z”，[TableA].[ColumnB] 有时会得到 [TableC].[ColumnD] 中不存在的值，因为，比方说，[TableA] 是从存在的对象中填充的在将代码作为“序列化 blob”运行时，内存中的数据表示形式和 [ColumnB] 值在被其他进程从 [TableC].[ColumnD] 中删除这些值之前填充。无论如何，这是为了举例，所以不要陷入“为什么会发生这种情况”，只要接受它。

要“解决”问题，这两种方法中哪种方法最好： 1. 在 [TableA] 上创建一个触发 on-INSERT 的触发器，将 [ColumnB] 更新为它应该是的值（并假设我有一个“映射”的坏值到好值）。或者，2. 每隔一小时/一分钟/运行更新查询的任何时间运行一个计划作业，以将所有可能的“坏”值更改为其相应的“好”值。

更一般地说，什么对性能更好和/或什么是最佳实践：触发器或定期计划作业？在上下文中，假设 [TableA] 通常大约有数十万行，一次插入 10-100 条记录，频率可能每隔几分钟到一天几次。

4

4 回答 4

9

在插入。

执行触发器就像回调——它们在逻辑上更合理，并且它们将任何延迟分散到每个查询中。进行持续检查（称为轮询或 cron-jobs）时，您会时不时地遇到更严重的滞后时刻。在几乎所有情况下，使用触发器/回调是更好的方法，因为在每个查询中添加 1 毫秒的延迟优于看似随机间隔的 100 毫秒的延迟。

于 2012-04-18T00:37:51.703 回答
1

触发器既是最佳性能也是实践，因为它们保持引用完整性并允许服务器优化性能。

于 2012-04-18T00:36:27.850 回答
1

通常不鼓励使用触发器，但是您的负载很轻，并且您的案例似乎是一个自然的触发器案例。考虑使用而不是触发器来避免对同一行进行两次操作（一次插入而不是插入和更新）。它可能是最简单和最可靠的解决方案（只要您在触发器中编写了不会导致整个操作崩溃的可靠代码）。

由于您正在考虑批处理作业，因此您不必担心时间问题。也就是说，您的应用程序可以在 1 分钟甚至 1 小时内不同步表。这是与触发器方法的主要区别，它将保证表始终保持同步。潜在的时间问题会让我感到不舒服。从好的方面来说，您不会面临使用触发器导致原始插入操作崩溃的风险。

如果您走这条路线，请考虑更改跟踪功能。更改跟踪将指示自上次检查以来已插入哪些行，因此您不必扫描整个表以查找新记录。或者，如果您的 TableA 有一个 INDENITY 主键或唯一键，您可以实现类似的设计，而无需更改跟踪功能。

于 2012-04-18T01:15:58.367 回答
0

您没有说您使用的是什么版本的 SQL Server，但如果是 2008+，您可以使用更改数据捕获来跟踪对“主”表的数据更改。然后，您可以定期在更改表上运行批处理，并对该小集合执行所需的任何处理。

于 2012-04-18T15:03:15.647 回答