我已经在网上和其他网站上阅读了有关触发器使用的各种帐户/意见，我在此尝试注意不要在此处创建重复的问题。
针对使用触发器提出的大部分推理是他们可能对其他人与数据交互产生的未知的，看不见的副作用。在我看来，这在企业场景中会更为普遍，在这种场景中，许多部门可能会将各种应用程序挂在公司的数据库中，并且一个部门的看不见的业务规则不应隐藏在可能影响他人或过时的触发器中。
我正在构建一个包含会计系统的产品。我发现触发器和计算字段的组合对于维护诸如发票总额（包括和排除gst）交易状态（如发票部分支付，全额支付，部分授权支付等）非常有用。
我已经证明使用一些非常具体的（原子）触发器来强制执行最常见的会计规则，理由是它们实施的“业务”逻辑不是真正的业务逻辑，而是数据完整性，这将简化某些报告未来我们或第三方的要求和我们的数据库必须在各种合格（或不是）“IT支持”的环境中生存下去。我们的普通用户并不真正了解计算机系统的架构或性质，并且会根据他们打开计算机或上网的能力，天真地信任任何人帮助他们使用计算机系统。
例如，我不希望发票状态被破坏，因为一些未知的“I.T. guru”或企业主的侄子认为他需要从表中删除几行或手动更改付款金额。
您是否认为普遍接受的对触发器使用的厌恶在企业场景中更为普遍，或者与使用其产品运送数据库的ISV有何关联？
答案 0 :(得分：1)
这取决于。当在数据库应用程序或RDBMS支持的客户端 - 服务器或n层应用程序中使用，例如在表上记录操作时，我发现触发器在企业和ISV场景中都很有用。
我会避免在事务中使用它们或实现业务逻辑，因为它们总是会使应用程序中可能受到影响的任何问题复杂化（因为很容易忘记它们存在或忽略它们的副作用）
此外，某些MPP数据库（例如EMC Greenplum）不允许用户定义触发器，因此如果您的应用可能需要横向扩展，这也会使问题复杂化。
您所说的一般厌恶是基于他们可以提出的问题，无论您是在编写企业软件还是您是ISV，这些都是有效的问题