我有一个请求允许动态表有1000列（由我的最终用户随机选择）。这对我来说似乎是一个坏主意。它是一个可自定义的表，因此它将混合使用varchar(200)和float列（float最适合应用程序c ++ double类型）。此数据库主要是遗留应用程序的索引，并充当报告存储库。这不是记录系统。该应用程序有数千个数据点，其中很少一部分可以标准化。
有关这方面的性能影响的任何想法？还是一个理想的表格大小来分解它？
由于我不知道20k值的选择中的哪些字段，最终用户将选择规范化表是不可行的。我可以将这些数据分成几个表，我必须动态管理（可以添加或下载字段。然后删除行，并重新解析记录系统以填充表。）我的偏好是推回和规范化所有20k位数据。但我没有看到这种情况发生。
答案 0 :(得分：15)
这对我来说闻起来很糟糕。
需要考虑的事项：
这些列中的大部分都包含NULL值吗？
许多人会被命名为Property001，Property002，Property003等......？
如果是这样，我建议您重新考虑数据规范化。
答案 1 :(得分：14)
来自SQL2005文档：
SQL Server 2005每个数据库最多可包含20亿个表，每个表最多可包含1,024个列。 （...）每行的最大字节数为8,060。对于具有varchar，nvarchar，varbinary或sql_variant列的表，放宽了此限制，这些列导致总定义的表宽度超过8,060字节。这些列中每一列的长度仍必须在8,000字节的限制范围内，但它们的组合宽度可能超过表中的8,060字节限制。
这些列的功能是什么？为什么不把它们分成主表，属性（查找表）和值？
答案 2 :(得分：9)
每当您觉得需要询问系统有什么限制时，您就会遇到设计问题。
如果你问“我可以在varchar中放入多少个字符？”那么你根本不应该使用varchars。
如果您真的想知道1000列是否合适，那么您迫切需要重新组织数据。 （归一化）
答案 3 :(得分：6)
MS SQL Server每个表的限制为1024列，因此您将在此边缘运行。使用varchar（200）列，您将能够超过每行8k字节的限制，因为SQL将在数据页上存储8k，然后溢出页面外的数据。
SQL 2008为这样的场景添加了稀疏列 - 您可以在其中包含大量具有空值的列。
答案 4 :(得分：4)
通常：表越宽，性能越慢。许多瘦桌子比桌子上的一块肥肉更好。
如果你的桌子很宽，那几乎肯定是一个设计问题。关于有多少是可取的，我没有真正的规则，我从来没有真正遇到过现实世界中超过20列的表格。只是按关系分组。毕竟这是一个RDBMS。
答案 5 :(得分：4)
这会产生巨大的性能和数据问题。它可能需要标准化。
虽然SQl服务器允许您创建一个具有超过8060字节的行的表，但它不会让您存储的数据多于其中的数据。你可能会有数据被意外截断（更糟糕的是，直到几个月之后才会发生这种情况，直到修复这个怪物既紧急又极其困难）。
查询这也是一个真正的问题。您如何知道要查找数据的1000列中的哪一列？是否每个查询都要求where子句中的所有1000列？
这个用户可以自定义的想法确实很可怕。为什么用户需要1000个字段来自定义？我见过的大多数应用程序都为用户提供了自定义某些字段的机会设置了一个小的限制（通常小于10）。如果他们需要定制那么多，那么应用程序就没有很好地定义客户实际需要的东西。
有时候作为开发者，你只需站起来说不，这是一个坏主意。这是其中一次。
关于你应该做什么（除了标准化），我认为我们需要更多的信息来指出你正确的方向。
而BTW，float是一种不精确的数据类型，不应该用于正在进行计算的字段，除非你喜欢不正确的结果。
答案 6 :(得分：2)
我不得不在这里不同意所有人......我知道这听起来很疯狂，但使用数百列的表格是我做过的最好的事情。
是的，许多列经常具有空值; 是的我可以将它标准化为几张桌子并进行转置; 是的，效率低下
然而，以无尽的方式分析列数据非常快速且容易
浪费而且不优雅 - 你永远不会建造任何有用的东西！
答案 7 :(得分：1)
太多了。任何超过50列的列，当您遇到问题时，您会在性能，代码维护和故障排除方面遇到麻烦。
答案 8 :(得分：0)
看起来很糟糕。我首先要确保数据是规范化的。这可能是你问题的一部分。这些数据会起什么作用？是报道吗？数据会改变吗？
我认为一张宽阔的桌子会成为一场噩梦般的表演和维护。
答案 9 :(得分：0)
您是否考虑过查看最终（1000列）表作为交叉表查询的结果？您的原始表格只有几列，但有数千条记录。
你能详细说明你的问题吗？我想没有人真正明白为什么你需要这1000列！