厦门建网站做优化,福州关键词快速排名,珠海网站建设公司网站,百度上首页原文地址 https://brandur.org/fragments/code-database-vs-app 数据库领域有一个长期存在的问题#xff1a;你是更愿意将应用逻辑放在更接近数据库本身的存储过程和触发器中#xff0c;还是置于数据库之上的应用程序代码中#xff1f;
没有客观正确的答案#xff0c;只有… 原文地址 https://brandur.org/fragments/code-database-vs-app 数据库领域有一个长期存在的问题你是更愿意将应用逻辑放在更接近数据库本身的存储过程和触发器中还是置于数据库之上的应用程序代码中
没有客观正确的答案只有不同的观点。我浏览了 Stack Overflow 等地方的大量热门文章并惊讶于普遍建议与常见事实的巨大差距。
可以肯定大多数公司在应用程序代码中编写逻辑。开发者都不会想到编写存储过程更不用说将领域逻辑放在存储过程中了。网络上很多人却建议将逻辑放在数据库中。
先说个人观点即使我因为类型、schema 和一致性而成为了关系数据库的拥护者对把代码放到数据库中也还是持保留意见。将代码放入数据库只在少数时候合适即使合适也要保持小规模、尽量少用。
对在数据库中编程的反对意见
数据库不适合应用程序编程的原因 不透明的后果 一旦设置了触发器如果不检查 schema简单如插入一行的操作也可能产生严重的后果。 同样的原因我也反对 ActiveRecord callbacks 这类东西。 调试、工具和测试 对数据库内函数都比较困难。 最多只能进行 printf 调试。很难使用开发者工具比如用 LSP 完成代码配置的噩梦 – LSP 必须主动与数据库交互才能知道哪些关系和字段可用SQL 函数会成为代码其他部分跳转到定义的死胡同。如果要也应该编写测试就应该在应用程序代码中编写这样…只要就地实现就可以了 部署和版本管理 仍然可以对存储过程进行版本管理 – 只能通过编写新的迁移就像数据库其他部分的版本管理一样。这就增加了更改代码的难度毕竟部署其他应用代码肯定更容易。 更改存储过程需要创建一个 CREATE OR REPLACE 函数其中包含函数的整个实现包括更改这样就无法像使用 git blame 那样查看每行的历史记录。 性能 数据库逻辑与数据本身同在所以有些情况下能提供最佳性能但一些重要方面却使性能更差 关系数据库通常是应用程序的单一阻塞点其他应用程序代码部署在一组可以访问关系数据库的并行容器中。一个容器的应用代码容易扩展只需部署更多的容器即可。数据库的扩展则比较困难。如果还需要运行数量未知的触发器操作速度就会更慢。例如当每一行都有一次隐藏触发批量操作就要花费数倍时间。当然可以暂时禁用触发器这就会失去触发器更多明显的好处。而且由于触发器不易被发现参见上文「不透明的后果」你可能无法明显感觉到操作速度变慢。 程序化 SQL 程序化 SQL 与 BASIC 和 COBOL 1 同属于最底层的编程语言编写体验很糟糕即使你熟悉。当然可以激活扩展从而使用其他语法更好的脚本语言但你真的想让 Python 虚拟机在你的数据库中运行吗
对在数据库中编程的支持意见
糟糕的意见
我在 Stack Overflow 上看到这样一些糟糕的论点 一致的实现 多个应用程序访问同一个数据库时使用存储过程是保证它们使用相同实现的唯一方法。 但出于多种原因在应用程序之间共享数据库并不是好主意在多个应用程序都可能向数据库写入数据的情况下共享数据库更糟Schema 属于哪个程序如何在 schema 变更时协调应用程序的部署。 性能 存储过程的性能很高因为它们与数据本身同位于数据库服务器上。 这是事实但依赖这一点很危险因为数据库的可扩展性有限任何利用这种局部性的做法都会给数据库带来很大压力。如上所述将工作外包给可轻松扩展的应用程序代码会更安全、更具可扩展性。 ACID 一致性 触发器是保证 ACID 一致性的唯一方法。 在一个看起来都是数据库专家的网站上发现这一点很奇怪。——并不是唯一的方法不然为什么有数据库事务
更好的意见
最后有几个更好的理由支持将代码放在数据库中 非常适合一些小而受限的模块 有一小部分常见模块非常适合触发器。例如一个很小的函数用来触发表上的 updated_at 时间戳 CREATE OR REPLACE FUNCTION set_updated_at()
RETURNS trigger
AS $$
BEGINNEW.updated_at : current_timestamp;RETURN NEW;
END
$$ LANGUAGE plpgsql;然后数据库中的每张表都会有这个触发器 CREATE TRIGGER team_set_updated_atBEFORE UPDATE ON teamFOR EACH ROWEXECUTE FUNCTION set_updated_at();在应用程序代码中可以实现这一点使用类似模型回调的方法但会带来大量重复一旦在某处遗漏就会造成错误。相比之下数据库版本的运行更可靠效果也更好。 实现深度一致性避免操作错误 举个例子假设我们有两个独立的账户表一个是在我们这里注册的账户另一个是通过身份提供商的 SSO 进入的账户。它们有很大区别因此我们要分别跟踪但它们是相关的概念账户可能拥有的资源如 API 密钥可能由其中一种类型或另一种类型拥有。 另一个名为 account_common 的表通过两个小操作增强一致性 确保两个不同类型的账户不会意外共享一个 ID充当通用资源如 API 密钥的外键目标 在添加账户或 SSO 账户时要确保为其插入 account_common 记录。在应用程序代码中插入额外的记录不方便且容易忘记因此我们用一个简单的触发器 CREATE OR REPLACE FUNCTION account_common_upsert() RETURNS TRIGGER AS $$BEGININSERT INTO account_common (id, kind) VALUES (NEW.id, TG_TABLE_NAME)ON CONFLICT (id, kind)DO NOTHING;RETURN NEW;END;
$$ LANGUAGE plpgsql;CREATE TRIGGER account_common_upsert BEFORE INSERT ON accountFOR EACH ROW EXECUTE FUNCTION account_common_upsert();
CREATE TRIGGER account_common_upsert BEFORE INSERT ON sso_accountFOR EACH ROW EXECUTE FUNCTION account_common_upsert();这些情况仍然存在上述数据库代码的缺点但也是将其放入数据库的好处大于成本的地方。
总之应该根据具体情况评估使用时将代码保持在较小的范围内。 更多资讯请关注 Bytebase 公号Bytebase
