答案 0 :(得分：1)
我首先强烈建议您添加“StockOnHand”，“ReservedStock”和“SoldStock” 到你的桌子。
现金销售将立即从“StockOnHand”中减去销售并将其添加到“SoldStock”，对于您将单独留下“StockOnHand”的订单，只需将销售额添加到ReservedStock，当库存最终开具发票时，您将减去从StockOnHand和预留库存中进行销售，并将其添加到“SoldStock”。
然后，业务用户可以选择StockOnHand是否只是StockOnHand - ReservedStock。
使用维护者StockOnHand数字将大大减少您的查询时间，相比之下，如果您搞砸了程序逻辑，那么这个数字可能会失败的风险很小。
如果您的客户非常幸运地在维护StockOnHand数字时遇到更新争用（即，他们可能在高峰时间处理超过五次销售），那么您可以采用以下方案： -
通过计算交货数量来计算StockOnHand数字 - 销售额等等。 确认销售后，在“今日销售”表中插入一行。 当您需要查询今天的库存总量并从当天的销售数据中减去它。
您还可以在每个产品上放置一个“库存检查阈值”，这样如果您开始拥有10,000个小部件的那一天，如果有人订购的数量少于100，则可以将CheckThreshold设置为100，而不必费心检查库存。如果某人订单超过100，则检查库存并重新计算新的下限阈值。
答案 1 :(得分：0)
您可以创建一个视图（或多个视图）来重新呈现您的库存吗？这将负责从同步触发器中进行计算，从而减慢您的事务。使用多个视图可以满足要求“不同的企业对何时应该减少StockOnHand有不同的想法”。假设您可以满足严格的要求，creating an indexed view可以进一步提高您的表现。
答案 2 :(得分：0)
只是我头脑中的一些想法：
您可以使用计算列（例如，每个商店的每个产品的SOH），而不是触发器（和持久性SOH数据）。但是，除非有＆gt;＆gt;否则评估这一点的性能影响可能会很糟糕。对源表的写入次数多于对计算列的读取次数。 （权衡是假设您计算SOH的唯一原因是您可以再次阅读它。如果更新CR的源数据的次数比您实际需要读取它的次数多，那么计算出的col可能会使感觉 - 因为只有在需要的时候它才是JIT评估。这可能是不寻常的 - 读取通常比大多数系统中的写入更频繁）
我猜你正在查看触发器的原因是因为SOH数据的源表是从大量的proc /代码更新的，以防止疏忽（而不是从每个调用recalc SPROC）源数据已被修改的适用点？）
不建议将IMHO置于数据库触发器中，因为这会对高容量插入/更新的性能产生负面影响，并且触发器的可维护性不佳。
SOH计算是否需要是实时的？如果没有，您可以实施一种机制来对重新计算的请求进行排队（例如，通过使用触发器来指示产品/位置余额是脏的），然后每隔几分钟运行一次重新计算服务以实现接近实时。任务关键计算（例如财务 - 就像你的＃6）仍然可以检测到SOH计算是脏的，然后在进行交易之前强制重新计算。
回复：3 - 哎哟。建议您在内部同意一致的（和行业可接受的）术语集（股票在手，股票承诺，股票在运输，收缩等），然后试图说服您的客户符合标准。但那当然是理想的世界！