C# 这是使用EAV的好例子还是不好

我有不同的产品类型，具有不同的属性。它们不能存储在单个表中，因为属性太不同。我目前正在考虑几个选项：EAV和每种类型的表

我的情况是，目前只有几种类型（比如说8种），但在不久的将来，几乎100%肯定的是，这种情况会增加。但是增长是由我控制的，不是由用户定义的。这将取决于我的产品类型的增长

---

我目前倾向于使用EAV（因为我可以很容易地涵盖增长，我想），但我不确定，因为我关心的是性能以及用我选择的语言（C#）对它们进行建模。我的问题是，考虑到上面的场景，我最好为每种产品类型创建一个表，并根据需要添加，还是这是一个使用EAV的好例子（或者说不好，可以接受）？

对于这个问题没有简单的好或坏的答案，因为它取决于很多事情

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

等等。 如果您对某些或所有这些问题回答“是”，EAV可能是一种很好的方式

关于C#，我在过去用它实现了一个EAV数据目录，并使用SQL Server上的实体框架（即RDBMS）。 这对我很好

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

请记住，模型对象不必与数据模型匹配。

---

例如，如果需要，您完全可以为每种类型的产品提供一个stronly类型的对象。

EAV不能很好地使用关系数据库。如果这就是你正在做的。（即连接到SQL）然后，我会说不。在开发时，承担风险，设计一个表pr类型的产品，或者制作一个包含产品类型各种属性的聚合表，然后将属性连接到相关表

因此，如果一个产品包含“齿轮”，那么你就有一个带有“齿数”、“半径”等的表格。 另一种产品类型具有“Scews”，其属性为“长度”、“里林”等。

---

如果一个产品类型既有齿轮又有螺钉，那么它只与这些子类型中的每一个相关。

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

• 经常为产品添加新属性

• 增加了大量的产品类型

• 执行完整产品类型搜索（或其他“完整产品类型”功能）

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

---

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

根据您选择的数据库，您可能能够将不同产品的不同属性存储为XML或JSON，这可能是比EAV更好的选择（许多人认为这是一种反模式）.我认为在这种情况下，肯定应该考虑使用noSQL，特别是因为他们对读操作的需求将超过对写操作的需求，并为他们提供产品更改所需的灵活性。但是，如果您没有成千上万的产品和客户，您绝对需要noSQL。这还取决于学习相关的技术、工具，在这一点上，数据的可靠性和一致性对您很重要。经典的RDBMS在某些方面保持了许多优势。上面我的意思是“您不一定需要NoSQL”，sorrytrue，当您选择想要使用的技术时，它始终是一个用例场景，说明您的期望以及您如何看待自己作为一个企业的发展。Pro/Con的列表总是有帮助的：）