数据库领域有一个长期存在的问题你是更愿意将应用逻辑放在更接近数据库本身的存储过程和触发器中还是置于数据库之上的应用程序代码中

Stack

可以肯定大多数公司在应用程序代码中编写逻辑。

开发者都不会想到编写存储过程更不用说将领域逻辑放在存储过程中了。

网络上很多人却建议将逻辑放在数据库中。

先说个人观点即使我因为类型、schema

和一致性而成为了关系数据库的拥护者对把代码放到数据库中也还是持保留意见。

将代码放入数据库只在少数时候合适即使合适也要保持小规模、尽量少用。

ActiveRecord

函数会成为代码其他部分跳转到定义的死胡同。

如果要也应该编写测试就应该在应用程序代码中编写这样…只要就地实现就可以了

部署和版本管理

只能通过编写新的迁移就像数据库其他部分的版本管理一样。

这就增加了更改代码的难度毕竟部署其他应用代码肯定更容易。

CREATE

数据库逻辑与数据本身同在所以有些情况下能提供最佳性能但一些重要方面却使性能更差

关系数据库通常是应用程序的单一阻塞点其他应用程序代码部署在一组可以访问关系数据库的并行容器中。

一个容器的应用代码容易扩展只需部署更多的容器即可。

数据库的扩展则比较困难。

如果还需要运行数量未知的触发器操作速度就会更慢。

例如当每一行都有一次隐藏触发批量操作就要花费数倍时间。

当然可以暂时禁用触发器这就会失去触发器更多明显的好处。

而且由于触发器不易被发现参见上文「不透明的后果」你可能无法明显感觉到操作速度变慢。

程序化

同属于最底层的编程语言编写体验很糟糕即使你熟悉。

当然可以激活扩展从而使用其他语法更好的脚本语言但你真的想让

Python

多个应用程序访问同一个数据库时使用存储过程是保证它们使用相同实现的唯一方法。

但出于多种原因在应用程序之间共享数据库并不是好主意在多个应用程序都可能向数据库写入数据的情况下共享数据库更糟Schema

属于哪个程序如何在

这是事实但依赖这一点很危险因为数据库的可扩展性有限任何利用这种局部性的做法都会给数据库带来很大压力。

如上所述将工作外包给可轻松扩展的应用程序代码会更安全、更具可扩展性。

ACID

在一个看起来都是数据库专家的网站上发现这一点很奇怪。

——并不是唯一的方法不然为什么有数据库事务

有一小部分常见模块非常适合触发器。

例如一个很小的函数用来触发表上的

updated_at

set_updated_at();在应用程序代码中可以实现这一点使用类似模型回调的方法但会带来大量重复一旦在某处遗漏就会造成错误。

相比之下数据库版本的运行更可靠效果也更好。

实现深度一致性避免操作错误

举个例子假设我们有两个独立的账户表一个是在我们这里注册的账户另一个是通过身份提供商的

SSO

进入的账户。

它们有很大区别因此我们要分别跟踪但它们是相关的概念账户可能拥有的资源如

API

记录。

在应用程序代码中插入额外的记录不方便且容易忘记因此我们用一个简单的触发器

CREATE

account_common_upsert();这些情况仍然存在上述数据库代码的缺点但也是将其放入数据库的好处大于成本的地方。

更多资讯请关注