Database 是否应将当前应用程序状态存储在数据库中？

我已经开始从事一个项目，在该项目中，Postgres数据库被用作系统架构中不可或缺的组件。这迫使我放弃了以前的观念，即数据库是用来存储东西的

有一个API可以将传入的请求转换为数据库查询/更新。这会导致数据库中的触发器通知另一个应用程序相应地更新实际系统

对我来说，这一切似乎都是多余的。这也是在一个相当关键的系统架构中，但我们无法保证了解底层系统故障，使其成为备份链，因为一切都是异步的。总之，我一点也不喜欢它。我的观点是，我们应该使用API和底层系统之间的直接通信立即从头开始重新启动，只使用数据库存储持久状态更新/用户信息等

---

我在这里真正想要的是有人在我最终与团队闹翻之前向我解释为什么我错了，但是所有的观点都是受欢迎的。

支持这种集成的唯一原因是它的低成本，特别是如果两个集成系统使用自己的专有技术，并且彼此之间存在不好的情况。此外，DB集成呈现出旧式的集成

你想要实现（或至少增加）的东西叫做“自主性”。这是一个太大的话题，我不想谈论，但我会根据你们的情况强调最重要的事情

触发器和存储过程几乎总是邪恶的。它总是导致数据库的“逻辑泄漏”，从而导致业务逻辑和整个应用程序的可移植性和可维护性差。存储过程唯一有用的是提高性能。但是有很多方法可以在没有它们的情况下调整性能

一旦您的应用程序通过DB连接，您就要处理它们之间的紧密耦合，因此它们彼此紧密依赖，因此这两个应用程序的可维护性和可重用性都会受到影响

通过DB以某种复杂的方式连接应用程序，您将来可能还会遇到扩展问题

使用DB解决方案调用您正在处理的与技术耦合的东西，这不是设计来实现的。因此，这是不好的，因为缺乏灵活性和未来可能的限制。如果使用一些非标准化的专有工具和协议，情况会更糟

今天（企业）的最佳实践是使用完全自治的应用程序和应用程序（非集成）非共享数据库，通过标准化协议进行通信，可能通过一些可靠的中间件。它更昂贵，但它提供了很多好处（可伸缩性、可维护性、灵活性等）

要决定你是否真的需要重写一些东西，首先你需要估计成本和收益。若它是一个大的遗产，紧密耦合的组成工作得很好，那个么最好不要碰它，若需要的话，创建像包装器一样的外观

最后,

我在这里真正想要的是有人向我解释我为什么 错

---

我不认为你错了。

在不了解相关要求的情况下，很难知道为什么它的架构是这样的。这样做肯定是有原因的，即使是被误导了。