用存储过程控制所有数据流的海量表的优缺点

Question

DBA (只有2年的google培训)已经创建了一个海量数据管理表(108列，并且还在不断增加)，其中包含系统中任何数据流的所有必要属性。我们简称这张表为BFT。

在这些列中：

10用于元数据引用。

15用于数据源和时间跟踪

用于文本数据的新/货币列的1个实例

用于多值数字更新的新/当前/增量/比率/范围列的10个实例:总计50列。

多值数字更新通常只需要2-5个更新组。

15K-1500K记录的批次被加载到BFT中，并由存储的procs处理，并使用逻辑验证这些记录，将它们洗牌到大约30个其他表中的永久存储中。

在大多数记录加载中，50-70的列在整个过程中都是空的。

我不是数据库专家，但是这个模型和过程似乎有点不对劲，但是我不知道为什么，我不想在没有提供替代方案的情况下抱怨。

鉴于对数据处理模型的这一非常小的见解，有人有想法或建议吗？是否可以相信数据库(SQL Server)能够有效地处理大多数为空列的记录，或者以这种方式处理会浪费大量的周期/内存等。

Answer 1

我通常有多个对应于输入负载的临时表。这些表可能对应于目标表，也可能不对应，但我们不会执行您所说的操作。如果他不喜欢有很多基本上是临时工作表的东西，可以将它们放到自己的模式中，甚至放到一个单独的数据库中。

至于空的列，如果它们没有在处理BFT的特定查询中被引用，这并不重要-然而，将发生的情况是，索引变得更加关键，所选的索引是非聚集覆盖索引。当使用BFT并选择表扫描或聚集索引扫描时，必须读取未使用的列并忽略或跳过，根据我的经验，这似乎肯定会影响处理。而使用非聚集索引扫描或查找时，读取的列较少，并且希望这不包括(M)任何未使用的列。

Answer 2

听起来他彻底改造了BizTalk。

Answer 3

规范化是这里的关键字。如果你有这么多的空值，你很可能会浪费大量的空间。对该表进行规范化还可以使该表中的数据完整性更易于实施。