DBA（只有 2 年的 google 培训经验）创建了一个海量数据管理表（108 列并且还在增长），其中包含系统中任何数据流的所有必要属性。好吧，将此表简称为 BFT。
在这些列中：
10 个用于元数据引用。
15 个用于数据源和时间跟踪
1 个用于文本数据的新/当前列
实例 10 个用于多值数值更新的新/当前/增量/比率/范围列实例：总计 50 列。
多值数值更新通常只需要 2-5 个更新组。
15K-1500K 记录的批次被加载到 BFT 中，并由存储的过程进行处理，并使用逻辑来验证这些记录，将它们洗牌到大约 30 个其他表中的永久存储中。
在大多数记录加载中，50-70 列在整个过程中都是空的。
我不是数据库专家，但是这个模型和过程似乎有点味道，但我不知道为什么要说原因，也不想抱怨而无法提供替代方案。
鉴于对数据处理模型的这种非常小的洞察力，是否有人有想法或建议？是否可以信任数据库（SQL Server）以有效地处理具有大部分空列的记录，或者以这种方式进行处理浪费了大量的周期/内存等。
听起来他重新发明了BizTalk。
规范化是这里的关键词。如果您有这么多 NULL 值，那么您很可能会浪费大量空间。规范化表还应该使该表中的数据完整性更易于实施。
我通常有多个与输入负载相对应的临时表。这些可能对应于目标表，也可能不对应，但我们不做你所说的。如果他不喜欢有很多基本上是临时工作表的东西，可以将它们放入自己的模式甚至单独的数据库中。
至于为空的列，如果在处理 BFT 的特定查询中没有引用它们，那也没关系 - 但是，会发生的情况是索引变得更加重要，因为选择的索引是非聚集覆盖索引。当使用 BFT 并选择表扫描或聚集索引扫描时，必须读取并忽略或跳过未使用的列，根据我的经验，这似乎肯定会影响处理。而使用非聚集索引扫描或查找时，读取的列更少，并且希望这不包括（m）任何未使用的列。
可能使事情变得更灵活的一件事（除了规范化）可能是创建一个或多个视图或表函数来呈现数据。特别是如果桌子不在您的控制范围内，这些将使您能够过滤掉虚假的废话并仅从桌子中获取您需要的东西。
但是，如果您要成为与那张巨大的桌子一起工作的人之一（并且每次必须打开时都皱着眉头），您可能想要胜过 DBA 的“设计”并规范化该野兽，也许让 DBA 创建一些视图和/或表函数来帮助您。
我目前正在使用一个类似但不是那么大的表，该表已经在我们的系统中使用了多年，并且有新的字段、索引和约束，相当仓促地加入了科学怪人的风格。不幸的是，其他一些工作组将结构视为福音，因此我们创建了这样的视图和功能，使我们能够以我们需要的方式“塑造”数据。