Sql 运行total-触发器还是查询？

以下哪种情况将a）提供更好的性能和b）更可靠/准确。我简化了流程和使用的表格。我会提供代码/工作，但这是相当简单的东西。我使用的是MS-SQL2008，但我假设问题与平台无关

1）从库存中删除一个项目（库存项目具有唯一ID），触发一个更新[tblSold]的触发器，如果ID不存在，则创建一个记录并添加一个值1，如果确实存在，则向当前值添加1。出售的细节记录在别处

• 当请求库存可用性时，根据物料ID从该表计算其可用性

2）当要求库存可用性时，它只需根据ID对[tblSales]中的数量求和即可

---

库存可用性将被大量要求，并且由于明显的原因，永远不会出错。

我将采用第一种方法，没有理由计算行数，当您可以从数据库中读取一个值时，触发器不会有任何不好的作用，因为你不会像要求数量那样频繁地销售商品。

我将扮演魔鬼的角色，支持前面的答案，并建议使用查询-以下是我的理由

• SQL是为读取而设计的，一个维护良好的数据库对数亿行数据没有问题如果您的数据索引和维护良好性能不应该成为问题
• 触发器可能很难跟踪，它们不太明确，并且会在后台更新信息——如果你忘记了它们，它们可能会成为一场噩梦。这是一个很小的问题，但在过去已经让我烦了很多次了
• 最重要的一点是，如果使用查询（假设它是正确的），您的数据永远不会失去同步，并且可以轻松地重新生成。连续计数将使这一点非常困难

---

最终，这是一个每个人都会有不同看法的设计决策。一天结束时，它将取决于您的偏好和设计。

一个触发器会随着时间的推移分散计算负载，以便进行快速读取。求和给读者带来了计算所需结果的负担。触发器更可能与现实不同步，但定期扫描表可以解决问题。而且物理库存总是与数据库同步。数据的未来是什么？如果你将15年的数据相加，以确定今天可用的小部件，那么你可能会遇到问题。您是否会在保留检查点（例如年终库存）的同时清除旧数据？您会将旧数据移动到历史记录表中吗？报告需要在很长的时间段内运行，但不是经常运行，我也不关心这些查询运行所需的时间长度。大部分检查将在最长6个月内完成。正如我在下面问Liath的那样，我担心的一个问题是在结果相同时反复运行此查询。是否会自动缓存/优化这些数据，或者是否有办法缓存它们？缓存不会超出表数据仍在内存缓冲区中的可能性，从而减少磁盘读取。您可以玩一个shell游戏，显式维护一个库存缓存表，其中的行由销售触发器失效，但随后您又回到了最初使用的一个稍微陌生的解决方案。在某些应用程序中，可以接受稍微陈旧的数据，例如，如果缓存值的时间小于5分钟，则足以在目录页上显示“库存”状态。当用户选择一个特定的项目，然后计算库存并更新缓存。我将不得不连接两个表，以便合计总数，这将增加查询开销-我关心的一个问题是在结果相同时反复运行此查询。是否会自动缓存这些数据，或者是否有缓存它们的方法？连接不是主要问题，我们在这里讨论的是每分钟有多少行和点击数？如果您真的那么担心，您当然可以将值存储在Totals列/表中的某个位置！注意在出现问题之前进行优化-如果在最坏情况下一分钟内可以处理10000个查询请求，请保持简单，但这只是在异常的高峰时间。我想你可能是对的，在发现问题之前，我正在努力优化。我想从一个最佳实践的方法来解决这个问题。这是一个相当大的使用量-我会先用简单的方法来实现它，如果需要的话进行优化。确保使用参数化查询为查询计划缓存提供机会！