国外是不是倾向于小项目的重复逻辑交由 DB 层去处理

前司在经历几次大版本迭代以及数据库从 Oracle->MSSQL->PostgreSql 的变更之后已经彻底将业务逻辑和数据库（以及任何中间件）解耦了

Supabase 是为了 mvp 而生的，不适合大规模的业务架构。

我的个人项目也在用 supabase 。

我是把用户和注册功能在前端直接调用 supabase 的 js 库来实现，不经过我的服务器，其他所有请求都要经过我的后端服务器转发，业务处理也都放在服务器

我这么做是因为我不熟悉用户注册登录这些，所以直接交给 supabase 接管。我也不熟悉 pg 库的内置函数功能，感觉维护和测试都不太方便。而且我个人比较喜欢使用 ORM ，所以我的 python 服务器是使用 ORM 直连 supabase 的 pg 数据库，没有使用 suapbase 的库来连接。

reddit 上也有一些外国网友表示他也是这么做的。

交给 DB 去做，是不是得有专门开发 DB 的工程师啊？我在工作中还没见过这个职位呢。。。

你要是说屎山项目，确实是。现在的项目不可能再把逻辑放 DB 层了。

按网友们的说法，上古时代，是经常这么做的。但是目前因为云服务的普及，中间件得以弹性伸缩，而数据库相比较伸缩难度较大，因此不在数据库中涉及业务逻辑。

1. 大多数系统除了 I/O 就是 DB 有瓶颈，因此尽量减轻 DB 负载是必要的。
2. 存储过程的开发维护成本远高于代码，所以能代码解决的肯定不做存储过程。祖传代码已经很难懂了，如果祖传代码套着祖传存储过程怕是以后这个点要变更得先开发和 DBA 结对编程梳理出来逻辑完了再开技术团队会议确定逻辑是否正确以及针对新需求的修改方案吧。