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

Question

staging表是一种反模式，当rpc（例如Java RMI或某种Web服务调用）或消息传递队列（例如JMS）是更好的解决方案时使用的反模式，或者是否存在通过分段更好地服务的问题表？

澄清：

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

这种反模式的潜在原因：

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

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

3）缺乏知识或DGAS（不给予^％$ @）态度

Answer 1

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

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

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

Answer 2

为什么他们会成为反模式？临时表对于将接收服务与处理服务分离非常有用。当两个这样的服务解耦时，您可以更好地处理错误和网络错误，因为所有消息都存储在临时表中。

Answer 3

我见过的唯一实时是报告原因，当生成报告时，使用非规范化表来保存数据。我不认为这是一个问题。

Answer 4

我的第一反应是肯定的，但主要是因为我的情况 - 你的可能会有所不同。我们有一个系统，其中一些相对时间敏感的信息需要从命令组件到接收器组件。将命令信息放入数据库表中，然后接收器轮询表以获取更新。这太可怕了。他们这样做了，所以会有一个数据库中的命令记录，但它最终只是让实际的命令永远占用，并且解耦有时会导致接收器与数据库不同步。

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

我迫不及待想要解决这个问题。