在浏览数据库时，我发现在批量插入表的主要版本之前，似乎只存在用于保存数据的表。例如，对于表Location，将有一个表Location_upload。除了包含_upload位列的processed版本外，这些表似乎相同。显然，数据被添加到_upload表中，然后批量作业会将内容加载到实际表中。我相信这份工作是每小时一次。
当我问为什么这样做时，它几乎归结为那些不再在这里工作的人认为它应该是这样的。我能想到的唯一原因是：
1）如果出现问题，您可以记录试图插入的内容。
这并没有多大意义，因为插入_upload表必须有效。如果有效，为什么不直接插入主表？
2）完成某种数据操作，批量处理速度更快，或者让用户看起来更快。
由于除了单个位列之外的表看起来相同，所以似乎也没有用。即使查找经历过程的行似乎也会提供相同的数据值。
还有什么其他理由想要拥有这种等候室风格的桌子结构？这是其他地方的常见做法吗？
答案 0 :(得分：2)
我做了很多数据集成。对于使用我的工作的批量导入，临时表是相当常见的。
我在一个系统中使用它们，因为我从一个不知道所有必要信息的外部系统导入数据。我需要在staging表中填充一个列，然后才能将其插入到实际的表中，并且该列是实际表中的NOT NULL列。我可以用SSIS做到这一点，但是a）我在编写它的时候并不熟悉SSIS，并且b）它对纯SQL的运行速度非常快，而且c）正如你所说，它留下了一个记录导入了哪些数据。
在另一个系统中，来自三个不同数据文件的数据被导入三个不同的临时表。但是，需要将来自这些文件的数据转换为大约15个不同的实时表的记录，包括一些非常复杂的实体属性值表。我定义了15个不同的VIEW，它们从3个源分段表以及数据库中已有的6个表中生成记录，然后执行MERGE语句来更新实时表。
现在，可以使用临时表执行此操作，但如果您每天（或每小时）需要它并保持桌子实际上有帮助，那么常规表就可以正常运行。
答案 1 :(得分：1)
这是一种常见的ETL模式。允许数据以较慢的速度累积（插入），然后可以修改它以适应业务规则，最后插入到实际数据中。这允许更短的阻塞（仅在最终批量插入时），它防止数据在被验证和转换时变得可见。此模式通常称为staging。