我想使用 Postgres 作为 web api 存储后端。我当然需要(至少一些)胶水代码来实现我的REST接口(和/或WebSocket)。我想到两个选择：
-
将大部分业务逻辑实现为存储过程PL/SQL，同时使用非常薄的中间层来处理REST/websocket部分。
-
中间层实现了大部分业务逻辑，并通过其抽象的数据库接口到达 Pg。
我的问题是，与灵活性、可扩展性、可维护性和可用性相比，上述设计可能带来的好处/障碍是什么？
我并不真正关心确切的中间层实现(它可以是php，node.js，python或其他)，我对实际架构设计选择的好处和陷阱感兴趣。
我知道选择 (1) 会失去一些灵活性，因为很难将系统移植到 oracle 以外的其他位置，并且我的用户将绑定到 postgres。就我而言，这不是很重要，无论如何，数据库都是系统不可或缺的一部分。
我对选择(2)时失去的好处特别感兴趣，以及这两种情况可能出现的陷阱。
我认为这两种选择都有其优点和缺点。 (2)方法良好且已知。大多数简单的应用程序和 Web 服务都在使用它。但有时，使用存储过程比 (2) 好得多。 以下是一些示例，恕我直言，这些示例非常适合使用存储过程实现：
-
跟踪行的更改。即，您有一些包含定期更新的项目的表格，并且您希望有另一个表格，其中包含每个项目的所有更改和更改日期。
-
自定义算法(如果函数可用作索引数据的表达式)。
-
您希望在多个微服务之间共享一些逻辑。如果每个微服务都使用不同的语言实现，则必须为每种语言和微服务重新实现业务逻辑的某些部分。使用存储过程显然有助于避免这种情况。
(2)方法的一些好处(当然有一些"然而"会让你感到困惑:D)：
您可以使用自己喜欢的编程语言来编写业务逻辑。 但是：在(1)方法中，您可以使用pl/v8或pl/php或pl/python或pl/任何扩展使用您喜欢的语言编写过程。
维护代码比维护存储过程更容易。 但是：有一些很好的方法可以避免代码维护的这种头痛。即：迁移，这对每种方法都是一件好事。 此外，您可以将函数放入自己的命名空间中，因此要将重新部署过程重新安装到数据库中，您只需删除并重新创建此命名空间，而不是每个函数。这可以通过简单的脚本来完成。
您可以使用各种ORM来查询数据并获得抽象层，这些抽象层可以具有更复杂的逻辑和继承逻辑。在 (1) 中，很难使用 OOP 模式。 我认为这是反对(1)方法的最有力论据，我不能为此添加任何"但是"。