当 rpc（如 Java RMI 或某种 Web 服务调用）或消息队列（如 JMS）是更好的解决方案时，暂存表是否是一种反模式，或者暂存表是否可以更好地解决问题？
澄清：
暂存表是指记录由一个或多个进程附加到一个或多个表的情况，然后由第二个或多个进程读取并对其进行操作。我不是指那些旨在反映间隔结束状态（一天结束、支付期结束等）的表格。在大多数情况下，登台表的模式非常模仿应用程序数据类型，例如客户或帐户。
这种反模式的潜在原因：
1) 两个进程的所有者之间的业务单元墙可防止写入或读取暂存的进程被修改。
2) 对 staging 写入或读取的进程信心不足，导致开发人员使用 table 来防止“以防万一发生故障”的数据丢失
3）缺乏知识或DGAS（不要给^％$@）态度
正如您所描述的，暂存表是大多数数据仓库或 BI 环境的重要组成部分。您可能会争辩说可靠/有弹性的 rpc 会做同样的工作，但我认为您是不正确的。
通过将数据拉到临时表中，您将其移出生产环境，可能会进行进一步的计算、汇总、重新索引、重新键入等，其中大部分都是“在数据库中”实现的。用 RPC 替换它，您将代码和 CPU 周期从 DB 移到应用服务器中，而没有真正的好处。例如，应用服务器崩溃的可能性要高得多——您不能（轻松）回滚 RPC。
当然，有很多方法可以在系统之间可靠地移动数据，临时表恰好是最简单、性能最高、可靠并且在开发方面最便宜的方法之一，并不总是意味着它们是正确的方法 - 但更多时候比不是。
为什么它们会成为反模式？暂存表对于将接收服务与处理服务分离非常有用。当两个这样的服务被解耦时，您对处理错误和网络错误的弹性要大得多，因为所有消息都存储在临时表中。
我唯一一次看到这是出于报告原因，即在生成报告时使用非规范化表来保存数据。我不认为这是一个问题。
我的第一反应是肯定的，但这主要是因为我的情况——你的情况可能不同。我们有一个系统，其中一些相对时间敏感的信息需要从命令组件传输到接收器组件。命令信息被放入数据库表中，然后接收器轮询表以获取更新。这太可怕了。他们这样做是为了在数据库中记录命令，但最终只会使实际命令永远持续下去，并且解耦有时会导致接收器与数据库不同步。
我宁愿看到 EMS（如 JMS）将消息广播到接收者和数据库插入器都侦听的主题，或者从指挥官到接收者的队列，然后接收者通知状态侦听器将其状态放入数据库。
我迫不及待地想修复那个代码。