Sql server 为什么要插入到表中，以便稍后上载到实际表中？

在浏览数据库时，我发现一些表似乎只存在于大容量插入到表的主版本之前，用于保存数据。例如，对于表

Location

，将有一个表

Location\u upload

。除了包含

已处理

位列的

\u上载

版本之外，这些表似乎是相同的。显然，数据被添加到

\u upload

表中，然后一个批量作业将把数据加载到实际的表中。我相信这份工作是每小时一次的

当我问为什么要这样做时，基本上可以归结为不再在这里工作的人认为应该这样做。我能想到的唯一原因是：

1） 如果出现问题，您将记录尝试插入的内容

这没有多大意义，因为插入到

\u upload

表中必须工作。如果可以的话，为什么不直接插入主表呢

2） 某些类型的数据操作可以更快地进行批量处理，或者让用户感觉更快

也似乎不起作用，因为表除了一个位列之外似乎是相同的。即使查找经过该过程的行，似乎也会得到相同的数据值

---

想要拥有这种候诊室风格的桌子结构还有什么其他原因？这是其他地方的常见做法吗？

这是一种常见的ETL模式。允许数据以较慢的速度累积（插入），然后可以修改数据以适应业务规则，最后插入到实际数据中。这允许更短的阻塞（仅在最终大容量插入时），它防止数据在验证和转换时变得可见。这个模式通常被称为。

我做了大量的数据集成。对于我使用的批量导入，暂存表非常常见

我在一个系统中使用它们，因为我从一个不知道所有必要信息的外部系统导入数据。我需要先填充staging表中的一列，然后才能将其插入到实际表中，而该列在实际表中是非空列。我可以用SSIS实现这一点，但a）我在编写它时对SSIS不太了解，b）它在纯SQL中运行得非常快，c）正如您所说，它会留下导入数据的记录

在另一个系统中，来自三个不同数据文件的数据被导入到三个不同的暂存表中。但是，这些文件中的数据需要转换为大约15个不同活动表的记录，包括一些非常复杂的实体属性值表。我定义了15个不同的视图，它们从3个源临时表以及数据库中已有的6个表生成记录，然后执行MERGE语句来更新活动表

---

现在，您可以使用临时表来实现这一点，但是如果您每天（或每小时）都需要临时表，并且将临时表放在身边实际上会有所帮助，那么常规表工作得非常好。

我们在这里使用临时表，这样，如果插入因任何原因失败，数据仍然存在，并且可以更正以稍后尝试插入，主要是EDI过程。