正确使用数据库功能进行业务逻辑

Question

我在 postgres 中有一个包含 147 个表的数据库；这些表包含由具有系统大部分逻辑的函数生成的数据，例如如何构建会计分录。

这些函数由java中的应用程序调用，该应用程序在代码中几乎没有业务逻辑。

此数据库结构用于不同的客户，其中一些功能对每个客户进行了小的调整，并在功能体中进行了注释。

1. 大多数逻辑都在数据库中的这种方法是否正确？

2. 如果您更新数据库中的一个函数并且我们必须将其传递给彼此，我们如何轻松区分哪个函数发生了更改？不要通过错误删除或替换客户端数据库中的更改？

Answer 1

两个查询 - 两个回复：

a) 将业务逻辑置于数据库中，防御强，对手强。许多支持/反对的论点都是不稳定的，仅对某些配置和环境有效。一些数据库没有很好的存储过程编程能力，一些公司没有很好的个人资源在相对不同的环境中进行编程。有些项目不需要真正有效的数据处理，更有价值的是单片部署。将业务逻辑放置到数据库中有一些论据（仅限非交互式过程！）。您必须将应用程序划分为交互式（表示）层和非交互式层（通常是最好的方法，您可以做什么）：

• 应用程序在数据处理层和数据表示层之间的自然分解
• 在异构环境中非常易于访问的 API - 数据库中的逻辑可以从 shell 脚本、所有语言、...
• 由于接近数据和处理单元而非常有效的数据处理（在 PostgreSQL 中它是相同的过程）。它消除了网络延迟、协议、层、驱动程序之间的转换——PL/pgSQL 与 PostgreSQL 核心数据库引擎在同一进程中运行，并使用相同的数据类型。
• 您可以基于存储过程创建 API，因此数据库层的任何更改对您和您的应用程序都是透明的。

一般我可以说，存储过程的威力在异构环境中更显着，而在单一的单一应用程序环境中则更少。

b) PostgreSQL 有一个 CREATE OR REPLACE FUNCTION 语句和基于快照的数据可见性 - 所以生产中的更新通常不是问题。您可以在事务下更新数据库字典（带函数）。