用EAV还是不用?

这个问题没有简单的好或坏答案,因为它取决于许多事情。

• 你有很多产品类型吗?
• 你认为它们将如何发展(想想当你将新领域添加到产品中时会发生什么)?
• 您需要处理产品的“变体”吗?
• 您打算添加全新的产品类型吗?

等。 如果你对一些或所有这些问题回答“是”,EAV可能是一个很好的方法。

关于C,我过去用它实现了EAV数据目录,并在SQL Server上使用实体框架(即RDBMS)。 它对我很好。

但是如果你需要处理很多产品,性能很快就会成为一个问题。你也可以找一个“nosql”解决方案,你想过吗?

请记住,模型对象不必与数据模型匹配。 例如,如果需要,可以为每种类型的产品完美地拥有一个stronly类型的对象。

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

• 经常为产品添加新的属性;

• 增加了很多产品类型;

• 执行完整的产品类型搜索(或其他“完整产品类型”功能);

我建议你使用EAV。 我已经用ADO.NET和MS SQL实现了以前的EAV数据结构,并且在性能上没有任何问题。

此外,莫顿博克以上建议使用“子类型”。但是,如果您想要实现一些“完整的产品类型”特性,我认为使用纯EAV模型会更加困难。

EAV在关系数据库中并不是很好。所以如果这就是你要做的。(即连接到SQL)那么我会说“不”。利用开发时间的冲击,设计一个产品的表pr类型,或者生成一个包含产品类型的各种属性的聚合表,然后将这些属性连接到相关的表。

所以,如果一个产品包含“齿槽”,那么你就有一个表,上面有“齿数”、“半径”等。 另一种产品类型有“scews”和“length”、“rilling”等属性。 如果一个产品类型同时具有齿槽和螺丝钉,它只与这些子类型中的每一个相关。