为避免使用触发器而提出的论点是否适用于 ISV 产品？
我已经阅读了这里和网络上其他地方关于使用触发器的各种帐户/意见，并且我试图小心不要在这里创建重复的问题。
反对使用触发器的大部分理由是它们可能对与数据交互的其他人产生未知的、看不见的副作用。在我看来，这种情况在企业场景中更为普遍，其中许多部门可能将各种应用程序挂在公司的数据库上，并且一个部门不可见的业务规则不应该隐藏在可能影响其他部门或变得过时的触发器中。
我正在构建一个包含会计系统的产品。我发现触发器和计算字段的组合对于维护诸如发票总额（包括和不包括商品及服务税）交易状态（如发票部分付款、全额付款、部分授权付款等）等字段非常有用。
我已经证明使用一些非常具体的（原子）触发器来执行最通用的会计规则是合理的，因为它们执行的“业务”逻辑并不是真正的业务逻辑，而是数据完整性，这将减轻我们的一些报告要求或将来的第三方并且我们的数据库必须在各种合格（或不合格）“IT 支持”的支持下在野外生存。我们的普通用户并不真正了解计算机系统的体系结构或本质，并且会天真地相信任何人会根据他们打开计算机或上网冲浪的能力来帮助他们使用计算机系统。
例如，我不希望发票状态被破坏，因为一些不知名的“IT 大师”或企业主的侄子认为他需要从表中删除几行或手动更改付款金额。
您认为普遍接受的对使用触发器的厌恶在企业场景中更为普遍，还是与 ISV 随其产品提供数据库相关？
I've read the various accounts / opinions on the use of triggers here and elsewhere on the web and am trying to be careful not to create a duplicate question here.
Much of the reasoning put forward against the use of triggers is the unknown, unseen side effects they may have for others interacting with the data. It seems to me that this would be more prevalent in an enterprise scenario where many departments may hang various applications off a company's database and unseen business rules of one department should not be hidden in triggers which could affect others or become outdated.
I am building a product which incorporates an accounting system. I am finding a combination of triggers and computed fields very useful for maintaining fields such as invoice totals (including and excluding gst) statuses of transactions (like invoice partly paid, fully paid, partly authorised for payment and so on).
I have justified the use of some very specific (atomic) triggers to enforce the most general of accounting rules, on the grounds that the "business" logic they enforce isn't really business logic but data integrity which will ease some reporting requirement for us or third parties in the future and that our database must survive in the wild with all manner of qualified (or not) "I.T. support" poking around at it. Our average user doesn't really understand the architecture or nature of a computer system and would naively trust anyone to help them with their computer system, based on their ability to turn on the computer or surf the web.
I don't want, for example, an invoice status to be broken because some unknown "I.T. guru" or business owner's nephew, thinks he needs to delete a few rows from a table or change a payment amount manually.
Do you think the generally accepted aversion to the use of triggers is more prevalent in an enterprise scenario or is it every bit as relevant to ISVs shipping a database with their product?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于。当在数据库应用程序或 RDBMS 支持的客户端服务器或 n 层应用程序中使用触发器来记录表上的操作时，我发现触发器在企业和 ISV 场景中都很有用。
我会避免在事务中使用它们或实现业务逻辑，因为它们总是会使应用程序中可能受影响的任何问题变得复杂（因为很容易忘记它们的存在或忽略它们的副作用）
此外，一些 MPP 数据库，例如 EMC Greenplum，不允许用户定义的触发器，因此如果您的应用程序可能需要横向扩展，这也会使事情变得复杂。
您所说的普遍厌恶是基于它们可能提出的问题，无论您是编写企业软件还是 ISV，这些都是合理的担忧
It depends. When used in a database application or RDBMS supported client-server or n-tier application for something like logging actions on a table, I have found triggers useful in both an enterprise and ISV scenario.
I would avoid using them in transactions or to implement business logic as they invariably complicate any issues in your app which might be affected (as it is easy to forget they are there or overlook their side effects)
Also, some MPP databases, such as EMC Greenplum, do not allow user defined triggers, so if your app may ever need to scale-out this will also complicate matters.
The general aversion you speak of is based on the issues they can present and these are valid concerns regardless of whether you are writing enterprise software or if you are an ISV