允许最终用户动态地向表中添加列

Question

我们正在开发一个带有SQL Server后端的.NET应用程序。客户端请求在部署应用程序后向实体动态添加自定义属性。

根据建议in a similar question，我们可以创建一个表，然后为每个自定义属性值（Entity-attribute-value模型）包含一行。但是，我们正在考虑允许最终用户实际修改表格（also suggested在同一问题中），即添加和删除列。

（编辑：，如评论中所述，DDL不会由用户或应用程序直接执行，而是通过存储过程确保一切顺利运行）

主要原因是：

• 改进了性能/可搜索属性
• 几乎总是要求属性显示为列，例如在用户界面的数据网格中或在Excel / PowerPivot中提取数据以进一步处理时。
• 数据是强类型的（与将所有属性值存储为varchar相反）
• 简化数据模型

我们应该注意哪些警告？

想到的事情是：

• 可能无法处理不断变化的数据结构的备份/还原操作
• 未正确更新以反映这些更改的从属对象（例如视图）（从属视图必须执行select * from table才能包含任何添加的列）。
• ...

非常感谢有关此方法的任何意见。

Answer 1

我使用第三方应用程序以各种方式处理此问题：

1. 大多数表都有一个表的“自定义”版本，其中包含各种字段以保存通常命名的数据类型：Number1，Date26，Text3等。因此，公司和公司自定义有1-1关系。

2. 列表是在具有ListID（以及用户设置架构的相应方式）和链接到主表的外键的表上创建的。该表有几个通用列，如＃1。

3. 创建自己的表格

4. 创建自己的视图和存储过程，并在应用程序中注册它们。这些数据集可以附加到数据网格和/或用于自定义报告。

用户可以在他们认为合适的时候标记他们的列（即Text1 =“Blah Blah Blah”）。在这种情况下有很多浪费的领域（尽管我的公司已经成功使用了大部分领域，包括Money47）并且它不是理想的性能，你无法击败我们拥有的近乎无限的灵活性。

这里的关键是这个客户愿意为这项能力支付多少以及持续的支持？如果您让他们在现有表上创建自定义字段，并且他们决定要更改无法顺利转换的数据类型，他们是否会期望您进行随机转换和转换？

我们可以聘请一名全职程序员来支付我们为此系统支付的费用。 SalesForce.com和类似网站具有此功能。我不认为您想进入一次性客户端应用程序。从长远来看，他们可能会付钱给你继续更新应用程序。