我正在使用SQL Server 2014.我正在创建多个表，总是包含500多列，这些表会相应地变化。
所以，我创建了一个稀疏列，以便我可以确定我的列数是否超过1024，这不是一个问题。现在出现了一个新问题：
无法创建具有大小为8710的稀疏数据的行，该行更大 超过允许的最大稀疏数据大小8023。
我知道SQL服务器连续只允许8 Kb的数据，我需要知道解决这个问题的方法。如果我需要计划转移到No SQL（Mongodb），它将在转换我的存储过程时产生多大的影响。
答案 0 :(得分：0)
普通表中的最大列数为1024.宽（稀疏）表中的最大列数为30,000。当您拥有大量列时，通常会使用稀疏列，但大多数列都是NULL。
在任何情况下，都有limit of 8060 bytes per row，因此稀疏列无效。
通常，表中有数千列表示数据库设计和规范化存在问题。
如果您确定需要将这千个值作为列而不是相关表中的行，那么我想到的唯一解决方法是垂直分区表。
例如，您有Table1列ID（主键）和其他1000列。将其拆分为Table1和Table2。每个都将具有与主键相同的ID和每个500列。这些表将使用外键约束以1：1链接。
答案 1 :(得分：0)
使用的数据类型和行中数据的密度为空的密度决定了稀疏列的有效性。如果填充表中的所有字段，则存储这些行实际上会产生更多开销，并且会使您更快地达到最大页面大小。如果是这种情况，则不要使用稀疏列。
查看可以从静态转换为可变长度数据类型（varchar，nvarchar，varbinary）的数量。这可能会在页面中为您带来一些额外的空间，因为可变长度字段可以放入溢出页面，但是对于指向溢出页面的指针，它会带来24字节的开销。我怀疑你认为稀疏列允许你存储30K列...这只是你有一个宽表的情况，其中大多数列都是NULL。
MongoDB不会是你的答案......至少在没有大量重构的情况下也是如此。您将无法利用现有的存储过程。它可能是最适合您的，但迁移到MongoDB时需要考虑很多事情。除非您恰好将关系结构中的数据保存为JSON文档，否则您的数据访问层将需要重建。我认为情况并非如此。
我假设你有宽桌子，人口密集......基于这个假设，这是我的建议。
按照Vladimir的建议对表进行分区，但创建一个将所有这些表连接在一起的视图，使其看起来像一个表。现在你拥有和以前一样的结构。然后在视图中添加“替代触发器”以更新表。这是一种可以获得所需内容而无需对代码进行重大重构的方法。你需要为触发器添加代码，但我的经验是它很容易编写，大多数时候我没有编写代码但是创建了一个脚本来生成我必须执行此操作的所有视图的代码这是重复的。