允许最终用户动态添加列到表

我们正在开发一个带有SQL Server后端的.NET应用程序。客户端请求在部署应用程序之后动态地将自定义属性添加到实体的能力。允许最终用户动态添加列到表

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

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

主要理由是：

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

是否存在，我们应该知道什么注意事项？

东西，脑海中出现：

备份/恢复，可能是无法处理不断变化的数据结构
依赖对象（如视图）未正确更新，以反映业务这些更改（依赖视图必须执行select * from table以包含任何添加的列）。
...

任何有关此方法输入是极大的赞赏。

来源

2013-01-22 bernhof

这可能是一种情况，其中属性为非规范化的[实体属性值]（http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model）模型作为行存储实际上是最有意义的。 – mellamokb

是的，请不要让用户将猴子扳手扔进你的数据库。至少通过EAV，你可以控制他们正在肆意破坏的东西...... http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav -anyar.aspx –

@AaronBertrand，感谢您的链接，这里有一些很好的观点。但是，他提到了导致我们探索非EAV方法的相同缺点。我们不允许用户直接执行DDL。一些存储过程可以作为猴子扳手驱蚊剂，确保添加/删除操作顺利进行。此外，只有合格的用户才有权执行这些操作。 – bernhof

我处理这个以多种方式第三方应用工作：

大多数表具有表与各领域的一个“自定义”版本保持统称为数据类型：数字1，Date26 ，Text3等）。所以有公司和CompanyCustom有1-1关系。
列表在具有ListID（以及用于设置架构的对应方式）和用于链接到主表的外键的表上创建。该表有几个通用列，如＃1。
创建自己的表
创建自己的视图和存储过程和应用程序进行注册。这些数据集可以附加到数据网格和/或在自定义报告中使用。

有一个用户界面可以标记他们的列，因为他们认为合适（即Text1 =“Blah Blah Blah”）。在这种情况下有很多浪费的领域（尽管我的公司已经成功使用了包括Money47在内的大部分领域），但它对性能并不理想，因此无法超越我们拥有的无限灵活性。

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

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

来源

2013-01-22 19:00:25 JeffO

如果我正确理解你，从第一天开始就存在“自定义”属性（Number1，Date26等），并且只是坐在那里等着填充数据？我不是这种方法的忠实粉丝，虽然它*消除了物理修改表的一些直接缺陷。 – bernhof

是的，这些字段随应用程序一起提供。我同意，这并不理想。 – JeffO

感谢您的输入。我们现在要避免动态方法，而是实现每个请求的新属性。 – bernhof

允许最终用户动态添加列到表

回答

相关问题