登台表/登台数据库是否为反模式？

staging表是一种反模式,当rpc(例如Java RMI或某种Web服务调用)或消息传递队列(例如JMS)是更好的解决方案时使用,或者是否存在更好的登台表服务问题？

澄清:

通过暂存表,我指的是那些记录通过进程附加到一个或多个表的情况,然后由第二个进程读取并由其执行.我并不是指表格中哪些表格反映了间隔状态的结束(一天的结束,支付期末等).在大多数情况下,登台表的模式非常类似于应用程序数据类型,例如客户或帐户.

这种反模式的潜在原因:

1)两个进程的所有者之间的业务单元Wall阻止写入或读取正在修改的分段的进程.

2)写入或从分段读取的进程的低可信度导致开发人员使用表来防止数据丢失"万一发生故障"

3)缺乏知识或DGAS(不给予^%$ @)的态度

正如您所描述的那样,临时表是大多数数据仓库或BI环境的重要组成部分.你可以说可靠/有弹性的rpc会做同样的工作,但我认为你是不正确的.

通过将数据提取到临时表,您将其移出生产环境,可能会进行进一步的计算,汇总,重新索引,重新键入等等,其中大部分都是在"数据库"中实现的.用RPC替换它会将代码和CPU周期从数据库中移出并进入应用服务器,这没有任何实际好处.例如,应用服务器崩溃的可能性要高得多 - 您无法(轻松)回滚RPC.

当然,有许多方法可以在系统之间可靠地移动数据,临时表恰好是最简单,最高性能,最可靠和开发方面最便宜的方式之一,并不总是意味着它们是正确的方法 - 但通常比不.

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