在 SQL Server 表中保存 800 多个控件属性是一种好方法吗？在线共享控制属性

如何解决在 SQL Server 表中保存 800 多个控件属性是一种好方法吗？在线共享控制属性

我为此搜索了很多次。实际上每个 SQL Server 表的最大 NO 列是 1024。问题是如果超过 655，SQL Server 会阻止查看器（IDK 为什么他们这样做......）

有些文章谈到了这一点：

Is there a hard limit as to how many columns can be returned in C# SqlDataAdapter Fill?

The results viewer cannot execute a query with more than 655 columns in the project list

没有实际解决方案或覆盖解决方案以使其在搜索后可接受...

实际上我需要保存到列的属性看起来像：

TreeMenu_OptionsView_ShowColumns                           bit
TreeMenu_OptionsView_ShowColumns_Default                   bit
TreeMenu_OptionsView_ShowFilterPanelMode                   nvarchar(50)
TreeMenu_OptionsView_ShowFilterPanelMode_Default           nvarchar(50)
TreeMenu_OptionsView_ShowFirstLines                        bit  
TreeMenu_OptionsView_ShowFirstLines_Default                bit
++ more than 600 properties

我的问题（特别是访问客户端 PC 中的控制属性）：

1. 将属性保存在 XML、json 文件中非常好，但在线修改它很难。只需访问每台 PC 即可为每台 PC 应用新文件。
2. 使用基于文件的方法。使其他连接到 SQL Server 实例的 PC 必须有文件。可能是重复或 PC3 或 PC4 的文件发生了什么问题。
3. 在连接的网络中检索文件不会像在任何 PC 中查询 SQL Server Select 那样快

我得到了只适用于短期的解决方案：将 SQL Server 表分成 2 个表；一个是控件属性，一个是控件外观

但也许几个月后需要添加新属性（40 多个新选项），因此我们将再次返回封闭的圆圈......

如果您对此有意见，我将不胜感激。也许 SQL Server 中有一些东西，比如缓存表（临时等）IDK

我只需要使用 SQL Server（欢迎使用其他方法）。

一目了然：我需要一个解决方案来创建诸如缓存表之类的东西，其中的列可以随时间增加

已编辑

在sql_variant的问题中，性能低下，不能与LIKE语句一起使用。和值必须插入一个 CAST() 函数以获得我们想要的类型。使用 NVARCHAR(MAX) 更好，它可以保存任何类型的值。

请参阅下面的 xanatos 回答。

解决方法

我从未见过使用属性数量增长如此之多的列。正如您所见，它变得很容易无法管理。

如果属性是用户连接的（可能是它们的设置），则像一个简单的表

(UserId,PropertyName,ValueAsNVarChar) 

可能更好。

如果您想有点深奥，SQL Server 支持可以包含任何值的 sql_variant。

如果属性是程序范围的，则

(PropertyName,ValueAsNVarChar) is enough,

或

(PropertyName,ValueAsVariant)

使用其他具有预期 .NET 数据类型的列是个好主意：

(PropertyName,ValueAsNVarChar,DotNetDataType) is enough,

其中 DotNetDataType 可以是 System.Int32、System.Int64、System.String、System.Boolean、System.DateTime 等等。