c# - 如果 EAV 是邪恶的，那么动态值使用什么？

Question

我需要创建数据库，其中 Accountgroup 表将包含动态字段，以便 Accounts 可以在需要时输入这些动态字段值。这可能并不重要，但我将 C# 与 EF 和 Linq 结合使用。

这对我来说很难，因为我从来没有做过那样的事情，而且自从我做了研究后，每个人都在说 EAV 系统很糟糕，你应该以不同的方式设计它，问题是没有人事后告诉 -怎么办？

所以也许你可以帮我，告诉我如何在不执行 EAV 的情况下实现类似的东西？

这就是我目前所拥有的。

2020 年编辑:

我只想编辑这篇文章，因为现在是 2020 年，对此有明确的答案:Postgres with jsonb type。 EF Core 支持它，因此您实际上可以毫无问题地保存和查询动态 json。

Answer 1

经验法则的问题在于，它们很快就会从“做 X 通常是个坏主意”变成“永远不要做 X”。

EAV 通常是一个坏主意，因为在很多方面它违背了关系模式的目的，因此它剥夺了关系 DBMS 和其他基于 RDBMS 的技术的许多特性和优势，例如 Entity Framework 之类的 ORM。

但是，对于某些设计问题，RDBMS 并不适合。有些非常不适合，以至于必须发明一种全新的技术(例如像 MongoDB 这样的 NoSQL DB)。

有时，从一组不完美的选项中，EAV 可能是留给您的最佳选择。如果您事先不知道(不能)知道您的模式是什么，那么 EAV 可能是您的最佳选择。如果您的模式被证明不重要，则尤其如此。例如，考虑一个在线产品目录，其中包含大量产品，每个产品都有一定数量的功能。您无法提前预测哪些产品将具有哪些功能。最后，您对产品功能所做的唯一一件事就是将它们转储到“功能:值(value)”列表中。在这种情况下，schema 并不是特别强大，因此用 EAV 击败它并不是特别有害。

最重要的是了解您的设计选择将对您的能力和操作产生什么影响。所有的设计都是折衷的。关键是要有意识地做出权衡。与其说“EAV 是邪恶的”，不如想想:“EAV 是一把上膛的枪，确保你知道你在用它指着谁的脚。”