正如维基百科所说
数据库触发器通常用于:
- 审核更改(例如,记录更改所涉及的用户和角色)
- 增强更改(例如,确保对记录的每次更改都带有服务器时钟的时间戳)
- 执行业务规则(例如,要求每张发票至少有一个行项目)等。
但是我们可以使用通用编程语言(尤其是 OOP)在业务层内部轻松完成这些事情。那么现代软件架构中数据库触发器的必要性是什么?为什么我们真的需要它们?
正如维基百科所说
数据库触发器通常用于:
- 审核更改(例如,记录更改所涉及的用户和角色)
- 增强更改(例如,确保对记录的每次更改都带有服务器时钟的时间戳)
- 执行业务规则(例如,要求每张发票至少有一个行项目)等。
但是我们可以使用通用编程语言(尤其是 OOP)在业务层内部轻松完成这些事情。那么现代软件架构中数据库触发器的必要性是什么?为什么我们真的需要它们?
如果所有数据仅由您的应用程序更改,它可能会起作用。但是还有其他我经常看到的案例:
还有其他不使用业务层的应用程序(例如执行导入的批处理作业等)
您不能使用简单的 SQL 脚本轻松地进行修补程序
除此之外,在某些情况下,您甚至可以将两者结合起来:在数据库中定义触发器,并使用 Java 来实现它。用于示例的 PostgreSql 支持用 Java 编写的触发器。对于 Oracle,您可以从 PL/SQL 触发器调用 Java 方法。您可以在 MS SQL Server 中定义基于 CLR 的触发器。
这样,并不是每个程序员都需要学习 PL/SQL,并且数据完整性由数据库强制执行。
想想表现。如果这一切都在应用程序中完成,很可能会有很多额外的 sql*net 往返,从而减慢应用程序的速度。在数据库中定义这些操作可确保始终强制执行这些操作,而不仅仅是在使用应用程序访问数据时。
当数据库处于控制状态时,您可以在中央位置(即数据库)上定义规则,而不是在应用程序中的许多位置上定义规则。
是的,您可以完全省略数据库触发器。
但是,如果您不能保证只能从应用程序层访问您的数据库(这是不可能的),那么您需要它们。是的,您可以在应用程序层中执行所有数据库逻辑,但是如果您有一个表 需要在更新时对其进行 X 处理,那么唯一的方法就是使用触发器。如果您不这样做,那么人们在您的应用程序之外直接访问您的数据库将会破坏您的应用程序。
您无能为力。如果您需要触发器,请使用触发器。不要假设与数据库的所有连接都将通过您的应用程序...