暂存表/暂存数据库是一种反模式吗？

Question

暂存表是一种反模式，它常常用于RPC（例如Java RMI或某种Web服务调用）或消息队列（例如JMS）等情况更适合的场景。但是有些问题使用暂存表可以更好地解决。

需要澄清的是:

暂存表是指通过一个进程将记录追加到表或多个表中，然后由第二个或多个进程读取并执行操作。这里所说的暂存表并不包括那些旨在反映区间结束状态（日终、薪资周期结束等）的表。在大多数情况下，暂存表的架构与应用程序数据类型（如客户或账户）非常相似。

导致这种反模式的潜在原因：

1. 两个进程的所有者之间的业务单位屏障阻止了写入或读取暂存表的进程的修改。

2. 对写入或读取暂存表的进程缺乏信心，开发人员使用表来防止数据丢失“以防万一”。

3. 缺乏知识或毫不关心态度。

- sal

Answer 1

如您所描述，中间表在大多数数据仓库或BI环境中是必不可少的一部分。您可以认为可靠/弹性的RPC会完成同样的工作，但我认为您是错误的。

通过将数据移动到中间表中，您将其移出生产环境，可能进行进一步的计算、摘要、重新索引、重新键入等操作，其中大部分都是“在数据库中”完成的。如果使用RPC替换这些操作，则将代码和CPU周期从数据库移出，并移到应用服务器中，而没有任何真正的好处。例如，应用服务器崩溃的风险要高得多 - 您无法（轻松地）回滚RPC。

当然，在系统之间可靠地移动数据有许多方法，而中间表只是其中最简单、最高效、最可靠且在开发方面最便宜的方法之一，但并不总是意味着它们是正确的方法 - 但往往是。

- MrTelly

Answer 2

他们为什么会成为反模式？暂存表对于将接收服务与处理服务解耦非常有用。当两个这样的服务解耦时，由于所有消息都存储在暂存表中，您更加具有处理错误和网络错误的弹性。

- Andrew Hare

Answer 3

我唯一看到这种情况是在报告生成时使用非规范化表来存储数据的情况下，出于报告目的。我认为对于这种用途，这不是一个问题。

- Craig

Answer 4

我的第一反应是肯定的，但这主要是因为我的情况 - 你的情况可能不同。我们有一个系统，其中一些相对时间敏感的信息需要从命令组件传递到接收器组件。命令信息被放入数据库表中，然后接收器轮询更新表格。这太糟糕了。他们这样做是为了在数据库中记录命令，但实际上只会使实际命令执行变得非常缓慢，并且解耦有时会导致接收器与数据库不同步。

我宁愿看到一个 EMS（如 JMS）将消息广播到接收器和数据库插入器都监听的主题，或者从指挥官到接收器的队列，然后接收器通知状态侦听器将其状态放入数据库。

我迫不及待地想修复那段代码。

- John Ellinwood