database - 您应该将当前应用程序状态存储在数据库中吗？

Question

我已经开始从事一个项目，其中使用 Postgres 数据库作为系统架构中的一个组成部分。这迫使我放弃了以前认为数据库可以很好地存储东西的观念。

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

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

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

Answer 1

支持这种集成的唯一原因是它的成本低，尤其是当两个集成系统使用自己的专有技术相互通信时。此外，数据库集成呈现旧式集成。

您想要实现(或至少增加)的目标称为“自治”。谈论这个话题太大了，但我会根据您的情况尽量强调最重要的事情。

1. 触发器和存储过程几乎总是邪恶的。它总是导致“逻辑泄漏”到数据库，从而导致业务逻辑和整个应用程序的可移植性和可维护性差。存储过程唯一可能有用的是提高性能。但是没有它们，有很多方法可以调整性能。
2. 一旦您的应用程序通过数据库连接，您就会处理它们之间的紧密耦合，因此它们彼此紧密依赖，因此两个应用程序的可维护性和可重用性都会受到影响。
3. 通过以某种复杂方式通过数据库连接应用程序，您将来可能还会遇到扩展问题。
4. 使用 DB 解决方案来调用您正在处理的与技术耦合的事物，而这并非设计用于此目的。因此，由于缺乏灵 active 和 future 可能的限制，它很糟糕。如果使用一些非标准化的专有工具和协议(protocol)，那就更糟糕了。

今天(企业)的最佳实践是使用具有应用程序(而非集成)非共享数据库的完全自主应用程序，通过标准化协议(protocol)进行通信，可能通过一些可靠的中间件。它更昂贵，但它提供了很多好处(可扩展性、可维护性、灵 active 等)。

要决定您是否真的应该重写某些内容，首先您需要估算成本和 yield 。如果它是一个工作良好的大型传统紧耦合组合，那么最好不要碰它，但如果需要的话创建类似 Facade 的包装器。

最后，

What i'm really looking for here is someone to explain to me why I'm wrong

我认为你没有错。