我有一个更复杂的场景，但我认为应该是可能的。
我有一个大的SPROC，其结果是一组人的一组特征。
所以表格看起来像这样：
Property |	 Client1 Client 2 Client3 ----------------------------------------------------------- Sex |	 M F M Age |	 67 56 67 Income |	 Low Mid Low
它是使用游标构建的，迭代不同的数据集。
我面临的问题是客户端和属性的数量不同，因此不同输入集的结果可能同样有效：
Property |	 Client1 Client 2 ------------------------------------------- Sex |	 M F Age |	 67 56 Weight |	 122 122
不同数量的属性很容易，这些只是额外的行。
我的问题是我需要声明一个具有不同列数的临时表。
可能有2个客户或100个。每个客户都保证最终列出所有房产。
什么SQL结构可以满足这个要求，如何声明它并将内容插入其中？
我不能只是翻转列和行，因为每个列都有可变数。
答案 0 :(得分：4)
这看起来就像你在服务器上使用Pivoting *。
虽然你可以做到这一点，但处理起来会非常尴尬 - 而且我不知道任何ORM对你来说效果很好（如果沿着这条路走下去）。
而不是透视，如何安排它更像（* 2）：
Client | Property | Value
------------------------------
Client 1| Sex | M
Client 1| Age | 67
通过这种方式，您仍然可以在应用程序中进行每个客户端透视操作以进行显示。
（* FWIW：您确实知道SQL Server 2005+有PIVOT Commands，对吗？使用游标保存您。）
（* 2这只是可能的方法。这很麻烦，而且Thomas建议规范化你的架构是一个更好，更可能更有效的选择。）
答案 1 :(得分：4)
首先，您应该考虑将设计标准化为：
Create Table ClientAttributes
(
ClientId ....
, Sex Char(1)...
, Age int...
, Income...
)
其次，SQL语言通常不适合动态列生成。为此，您必须在运行时（a.k.a.动态SQL）将SQL语句构建为字符串。最好在中间层或报告引擎中而不是在T-SQL中执行此操作。
第三，无限灵活的设计，你根本不知道属性或实例的数量或类型，根本不是一个设计。每个表表示具有已知属性的实体的集合。它们不是任意数据。属性（列）需要在设计时知道，否则你冒险Cthulhu设计，除了混乱缰绳。
Will Hughes的建议是使用实体 - 属性 - 值设计（a.k.a. EAV）。正确地执行EAV需要巨大的量纪律。它只有在被视为一团数据时才有效。即，没有开发人员可以过滤任何特定属性（即查询特定属性名称的查询的硬代码），对值进行计算，您将永远无法确保特定值之间的一致性。如果你可以维持这种规则，那么任意一团数据作为有限部分可以使用更大的设计。但是，一旦你决定硬编码寻找特定属性的查询，你就走上了黑暗的道路，永远将它掌控你的命运。随着数据库的增长，性能将显着下降。您将没有数据完整性（例如，您有两个名为“Age”和“Client Age”的属性，其中一些值为整数，其他值为文本）。 EAV可能是一个难以维持的噩梦。维护，报告，查询等具有标准化设计要好得多。