稀疏列大小限制解决方法答案

【问题标题】：Sparse column size limitation workaround稀疏列大小限制解决方法
【发布时间】：2017-01-12 08:01:03
【问题描述】：

我使用的是 SQL Server 2014。我正在创建多个表，总是有超过 500 列，这些列会相应变化。

所以，我创建了一个稀疏列，这样我就可以确定我的列数是否超过 1024 不会有问题。现在有一个新问题：

无法创建包含大小为 8710 的稀疏数据的行，该数据更大超过允许的最大稀疏数据大小 8023。

我知道 SQL Server 只允许连续 8 Kb 的数据，我需要知道如何解决这个问题。如果我需要计划迁移到 No SQL (Mongodb)，它将对转换我的存储过程产生多大影响。

【问题讨论】：

标签： sql sql-server mongodb sql-server-2014

【解决方案1】：

普通表的最大列数为 1024。宽（稀疏）表的最大列数为 30,000。当你有很多列时，通常会使用稀疏列，但大多数是NULL。

无论如何，有limit of 8060 bytes per row，所以稀疏列无济于事。

通常，表中有数千列表明数据库设计和规范化存在问题。

如果您确定需要将这千个值作为列而不是相关表中的行，那么想到的唯一解决方法就是垂直分区表。

例如，您有一个 Table1，其中包含 ID 列（主键）和 1000 个其他列。将其拆分为Table1 和Table2。每个都将具有相同的 ID 作为主键，每个都有 500 列。这些表将使用外键约束 1:1 链接。

【讨论】：

同意，但问题是我现在表中只有 863 列。但它正在抛出错误。
您达到的限制不是列数，而是每行 8060 字节。我能想到的唯一解决方法是将表格垂直拆分为多个表格，每行的字节数更少。
这太费时间和精力了，或者有什么办法可以将表移动到nosql数据库并使用sql存储过程？
@user2956568，对不起，我对nosql数据库一无所知。
无论如何，干杯伙伴。

【解决方案2】：

所使用的数据类型以及一行中有多少数据为空的密度决定了稀疏列的有效性。如果填充了表中的所有字段，则存储这些行实际上会产生更多开销，并且会导致您更快地达到最大页面大小。如果是这种情况，请不要使用稀疏列。

查看您可以将多少个静态数据类型转换为可变长度数据类型（varchar、nvarchar、varbinary）。这可能会在页面中为您购买一些额外的空间，因为可以将可变长度字段放入溢出页面，但确实会为指向溢出页面的指针带来 24 字节的开销。我怀疑您认为稀疏列将允许您存储 30K 列...这只是您有一个大多数列为 NULL 的宽表的情况。

MongoDB 不会是你的答案……至少在没有大量重构的情况下不会。您将无法利用现有的存储过程。它可能最适合您，但在迁移到 MongoDB 时需要考虑很多事情。您的数据访问层将需要重建，除非您碰巧将数据保存在关系结构中作为 JSON 文档:)。我认为情况并非如此。

我假设您有很宽的桌子，而且桌子很密集......基于这个假设，这是我的建议。

按照 Vladimir 的建议对表进行分区，但创建一个视图，将所有这些表连接在一起，使其看起来像一个表。现在你的结构和以前一样。然后在视图中添加一个代替触发器来更新表。这是一种无需对代码进行重大重构即可获得所需内容的方法。您需要为触发器添加一些代码，但我的经验是它很容易编写，而且大多数时候我没有编写代码，而是创建了一个脚本来为我必须这样做的所有视图生成代码这是重复的。

【讨论】：