使用存储过程控制所有数据流的大规模表的优点和缺点

Question

DBA（只有2年的谷歌培训）创建了一个海量数据管理表（108列和不断增长），包含系统中任何数据流的所有必要属性。好吧，简称BFT。

这些专栏：
10用于元数据参考 15用于数据源和时间跟踪
用于文本数据的1个新/ curr列的实例
用于多值数值更新的10个新/当前/增量/比率/范围列实例 ：总共50列。

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

批量的15K-1500K记录被加载到BFT中并由具有逻辑的存储过程处理，以验证这些记录将它们拖放到大约30个其他表中的永久存储器中。

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

我不是数据库专家，但这个模型和过程似乎闻起来有点，但我不知道为什么，并且不想抱怨而不能提供替代品。

鉴于对数据处理模型的这种非常小的洞察力，有没有人有想法或建议？可以信任数据库（SQL Server）来有效地处理大多数空列的记录，或者以这种方式处理会浪费大量的周期/内存等。

Answer 1

听起来他重新发明了BizTalk。

Answer 2

标准化是此处的关键字。如果你有这么多的NULL值，你可能会浪费很多空间。规范化表还应该使该表中的数据完整性更容易实施。

Answer 3

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

对于空的列，如果在处理BFT的特定查询中没有引用它们并不重要 - 但是，将会发生的情况是索引变得更加重要，因为选择的索引是非聚集覆盖索引。使用BFT并选择表扫描或聚簇索引扫描时，必须读取并忽略或跳过未使用的列，这肯定会影响我的体验处理。使用非聚集索引扫描或搜索时，会读取较少的列，并且希望这不包括（m）任何未使用的列。

Answer 4

可能使事情变得更灵活（除了规范化）之外的一件事可能是创建一个或多个视图或表函数来呈现数据。特别是如果桌子在你的控制范围之外，这些将使你能够过滤掉虚假废话，并从桌子上只抓取你需要的东西。

然而，如果你将成为那个与之合作的人之一（并且每次你必须皱着眉头皱眉）这个庞大的桌子，你可能想要胜过DBA的“设计”并使那个野兽正常化，也许给DBA创建一些视图和/或表函数来帮助你输出。

我目前使用的是一个类似但不那么庞大的桌子，这个桌子已经在我们的系统上使用了多年，并且已经有了新的领域，索引和约束而非匆忙地加入了弗兰肯斯坦风格。不幸的是，其他一些工作组依赖于结构作为福音，所以我们创建了这样的视图和函数，使我们能够按照我们需要的方式“塑造”数据。