当 rpc(例如 Java RMI 或某种 Web 服务调用)或消息队列(例如 JMS)是更好的解决方案时，暂存表是否是一种反模式，或者是否有问题可以通过暂存更好地解决表？
澄清一下:
我所说的暂存表是指记录被一个进程附加到一个或多个表的情况，然后由第二个或多个进程读取并对其进行操作。我不是指那些旨在反射(reflect)间隔状态结束(一天结束、支付期结束等)的表格。在大多数情况下，登台表的架构非常模仿应用程序数据类型，例如客户或帐户。
此反模式的潜在原因:
1) 两个进程所有者之间的业务单元墙防止写入或读取暂存的进程被修改。
2) 对写入暂存或从暂存读取的进程信心不足导致开发人员使用表来防止数据丢失“以防出现故障”
3) 缺乏知识或 DGAS(不要给出 ^%$@)的态度
最佳答案
正如您所描述的，暂存表是大多数数据仓库或 BI 环境的重要组成部分。您可能会争辩说可靠/弹性 rpc 会完成同样的工作，但我认为您是错误的。
通过将数据拉到暂存表，您将其移出生产环境，可能会进行进一步的计算、汇总、重新索引、重新键入等等，其中大部分是在数据库中实现的'.用 RPC 替换它，您将代码和 CPU 周期从数据库中移出并移入应用程序服务器中，而没有任何实际好处。例如，应用服务器崩溃的可能性要高得多——您不能(轻松地)回滚 RPC。
当然，有很多方法可以在系统之间可靠地移动数据，暂存表恰好是最简单、性能最好、可靠且在开发方面成本最低的方法之一，并不总是意味着它们是正确的方法 - 但通常情况下。
关于database - 登台表/登台数据库是一种反模式吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/633006/