Postgresql 存储过程中的业务逻辑与中间层

我想使用Postgres作为web api存储后端。我当然需要（至少一些）胶水代码来实现我的REST接口（和/或WebSocket）。我想有两种选择：

将大部分业务逻辑实现为存储过程PL/SQL，同时使用非常薄的中间层来处理REST/websocket部分

中间层实现了大部分业务逻辑，并通过其抽象数据库接口到达Pg

我的问题是，在灵活性、可伸缩性、可维护性和可用性方面，与其他设计相比，上述设计可能带来哪些好处/障碍

我并不真正关心确切的中间层实现（它可以是php、node.js、python或任何东西），我感兴趣的是实际架构设计选择的好处和缺点

我意识到，选择（1）会失去一些灵活性，因为很难将系统移植到oracle以外的地方，而且我的用户将绑定到postgres。在我的例子中，这不是很重要，数据库本来就是系统的一个组成部分

---

我特别感兴趣的是在选择（2）的情况下失去的好处，以及两种情况下可能出现的陷阱

我认为这两种选择各有利弊。 （2） 方法是好的和众所周知的。大多数简单的应用程序和web服务都在使用它。但有时，使用存储过程比（2）要好得多。 以下是一些示例，IMHO很适合用存储过程实现：

• 跟踪行的更改。也就是说，您有一些表，其中包含定期更新的项目，您希望有另一个表，其中包含每个项目的所有更改和更改日期

• 自定义算法，如果您的函数可以用作索引数据的表达式

• 您希望在多个微服务之间共享一些逻辑。如果每个微服务都是使用不同的语言实现的，那么您必须为每个语言和微服务重新实现业务逻辑的某些部分。使用存储过程显然有助于避免这种情况

（2）方法的一些好处（当然有些“然而”会让你困惑：D）：

• 您可以使用自己喜欢的编程语言编写业务逻辑。 然而：在（1）方法中，您可以使用pl/v8或pl/php或pl/python或pl/任何使用您喜欢的语言的扩展来编写过程

• 维护代码比维护存储过程更容易。 然而，有一些很好的方法可以避免代码维护带来的麻烦。例如：迁移，这对每种方法都是一件好事。 另外，您可以将函数放入自己的命名空间中，所以要将重新部署过程重新安装到数据库中，您只需删除并重新创建这个命名空间，而不是每个函数。这可以通过简单的脚本来完成

• 您可以使用各种ORM来查询数据并获得抽象层，这些抽象层可以具有更复杂的逻辑和继承逻辑。在（1）中，很难使用OOP模式。 我认为这是反对（1）方法的最有力的论据，我不能对此添加任何“然而”

---

请参阅另一个线程：