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

Question

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

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

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

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

Answer 1

支持这种集成的唯一原因是它的低成本，特别是如果两个集成系统使用自己的专有技术相互传播不良。此外，DB 集成呈现了旧的集成风格。

您想要实现（或至少增加）的称为“自治”。这是一个太大的话题，无法谈论，但我会根据您的情况尝试突出最重要的事情。

触发器和存储过程几乎总是邪恶的。它总是导致“逻辑泄漏”到数据库，从而导致业务逻辑和整个应用程序的可移植性和可维护性不佳。存储过程唯一可能有用的是提高性能。但是有很多方法可以在没有它们的情况下调整性能。
一旦您的应用程序通过数据库连接，您就在处理它们之间的紧密耦合，因此它们彼此紧密依赖，因此两个应用程序的可维护性和可重用性都会受到影响。
通过以某种复杂的方式通过 DB 连接应用程序，您将来也可能会坚持扩展。
使用 DB 解决方案来调用您正在处理的与技术耦合的事情，这并非旨在做到这一点。因此，由于缺乏灵活性和未来可能存在的限制，这很糟糕。如果使用一些非标准化的专有工具和协议，效果会更差。

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

要决定你是否真的应该重写一些东西，首先你需要估计成本和收益。如果它是一个工作良好的大型遗留紧密耦合组合，那么最好不要触摸它，但如果需要，创建类似于 Facade 的包装器。

最后，

我真正在这里寻找的是有人向我解释为什么我错了

我不认为你错了。