存储数据的最佳方法，属性可以变化

Question

请先阅读上一个问题：T-SQL finding of exactly same values in referenced table

这个question的主要目的是找出这种存储数据的方法是否有效。

也许最好摆脱PropertyValues表。并在PropertyValues nvarchar(max)表中使用其他Entities列而不是它。例如，而不是

EntityId  PropertyId  PropertyValue
1         4           Val4
1         5           Val5
1         6           Val6

表格，我可以将这些数据存储在PropertyValues列中：“4:Val4;5:Val5;6Val6”

作为替代方案，我可以将XML存储在PropertyValues列....

中

您如何看待这里的最佳方法？

[ADDED] 请记住：

1. 属性集必须可自定义
2. 对象将具有许多属性（大约从20到120）。数据库将包含数千个对象

[ADDED] PropertyValues表中的数据将经常更改。实际上，我存储配置的产品。例如，admin配置衣服具有“类型”，“大小”，“颜色”，“按钮类型”，“标签类型”，“标签位置”等属性...用户将从系统中选择这些属性的值。因此，PropertyValues数据无法有效缓存。

Answer 1

如果您使用多值属性（即4:Val4;5:Val5;6Val6）实施解决方案，您将会讨厌自己。

XML稍微好一些，因为有XQuery函数可以帮助您提取和解析值。但是XML类型在SQL Server中实现为CLR类型，并且使用起来非常慢。

这个问题的最佳解决方案就是你拥有的。如果列可以是任意数量的数据类型，请使用sql_variant类型。理想情况下，您可以将其重构为多个表/实体，以便数据类型可以更具体。

Answer 2

我使用类似的项目（网店生成器）。因此，每个产品都有属性，每个属性都有一组值。这是不同的表。对于所有这些，有几种语言的翻译。 （因此存在用于属性和值转换的附加表）。

为什么我们选择这样的解决方案？因为每个客户端都应该有相同方案的数据库。所以这样的数据库方案非常有弹性。

那么这个解决方案呢？一如既往，“它取决于” - ））

1. <强>存储即可。如果您的价值经常用于不同的产品，例如属性“大小”和大小值将经常重复的衣服，您的属性/值表将更小。同时，如果值相当独特且可重复（例如，书籍的属性“页数”值），您将获得一个足够大的值表，其中每个值都将链接到一个产品。
2. 的速度即可。这个方案不是项目中最薄弱的部分，因为这里的数据很少会被改变。并且请记住，您始终可以对数据库方案进行非规范化以准备类似DW的解决方案。如果数据库部分也很慢，您可以使用缓存。
3. 弹性这是解决方案中最强大的部分。您可以轻松添加/删除属性和值，并始终将值从一个属性移动到另一个属性！

所以回答你的问题并不简单。如果准备具有未知属性和值的弹性方案，则应使用不同的表。我建议你记住将值存储在CSV字符串中。最好将其存储为XML（键入和索引）。

<强>更新

我认为，如果与用户订单进行比较，PropertyValues不会经常更改。但是如果你怀疑，你应该使用非规范化表或索引视图加速。无论如何，在大量行上更改XML / CSV将会有很差的性能，因此“单独的表”解决方案看起来不错。

Answer 3

SQL客户咨询小组（CAT）有一份专门为您编写的白皮书：Best Practices for Semantic Data Modeling for Performance and Scalability。它经历了EAV建模的常见缺陷，并建议如何设计可扩展的EAV解决方案。