这是使用EAV还是不使用的好案例

Question

我有具有不同属性的不同产品类型。由于属性太不同，因此无法将它们存储在单个表中。我目前正在查看几个选项：EAV和每种类型的表格。

我的情况是，目前只有几种类型（假设是8种），但是在不久的将来，几乎可以肯定100％地确定这种类型。但是增长是由我控制的，它不是由用户定义的。扩大产品类型将取决于我。

我目前倾向于使用EAV（因为我可以轻松应对增长-我认为），但是我不确定，因为我关注性能以及如何以自己选择的语言对其建模（ C＃）。我的问题是，考虑到上述情况，我是否应该为每种产品类型创建一个表并根据需要添加表，还是使用EAV是一个好案例（或者甚至还不错，可以接受）？ / p>

Answer 1

对此问题没有简短的好或坏答案，因为它取决于很多事情。

• 您有很多产品类型吗？
• 您如何看待它们中的每一个（想想在向产品中添加新字段时会发生什么）？
• 您需要处理产品的“变体”吗？
• 您打算添加全新的产品类型吗？

等等 如果您对某些或所有这些问题的回答为“是”，则EAV可能是一个不错的选择。

关于C＃，我过去已经用它实现了EAV数据目录，并在SQL Server（即RDBMS）上使用了Entity Framework。 对我来说很好。

但是，如果您需要处理很多产品，性能很快就会成为问题。您还可以考虑使用“ NoSQL”解决方案吗？

请记住，您的模型对象不必与数据模型匹配。 例如，如果需要，您可以为每种类型的产品完美地设置一个str类型的对象。

Answer 2

在很大程度上取决于将在实体上执行的操作。如果您愿意：

• 经常向产品添加新属性；

• 添加很多产品类型；

• 实施完整产品类型搜索（或其他“完整产品类型”功能）；

我建议您使用EAV。 我过去使用ADO.NET和MS SQL实现了EAV数据结构，并且在性能上没有任何问题。

此外，上面的Morten Bork建议使用“子类型”。但是，如果您想实现某些“完整产品类型”功能，那么我认为使用纯EAV模型会更加困难。

Answer 3

EAV在关系数据库中不能很好地发挥作用。因此，如果您正在这样做。 （IE连接到SQL）然后我会说不。以开发时间为重，设计产品的表pr类型，或创建一个包含产品类型各种属性的汇总表，然后将这些属性连接到相关表。

因此，如果产品包含“齿轮”，则您的表中包含“牙齿计数”，“半径”等。 另一种产品类型具有“ Scews”，其属性为“ Length”，“ riling”等。 而且，如果产品类型同时具有嵌齿轮和螺丝钉，则仅与这些子类型相关。