我需要创建一个数据库，其中Accountgroup表将具有动态字段，以便Accounts可以在需要时输入这些动态字段值。可能并不重要，但是我正在将C#与EF和Linq一起使用。
对我来说很难，因为我从来没有做过这样的事情，而且由于我进行了研究，每个人都在说EAV系统太可怕了，您应该以不同的方式进行设计，问题是后来没人告诉我-怎么做？
因此，也许您可以帮助我，并告诉我如何在不进行EAV的情况下实现类似的功能？
到目前为止，这就是我所拥有的。
2020年编辑:
我只想编辑此帖子，因为它是2020年，并且对此有明确的答案:jsonb类型的Postgres。 EF Core支持它，因此您实际上可以保存和查询动态json，而不会出现任何问题。
最佳答案
经验法则的问题是，它们很快从“做X通常是个坏主意”变为“从不做X”。
EAV通常是一个坏主意，因为它在许多方面都无法达到关系模式的目的，从而剥夺了关系DBMS以及基于RDBMS构建的其他技术(例如诸如 Entity Framework 之类的ORM)的许多功能和优势。
但是，某些设计问题不是RDBMS的最佳选择。有些不合适，因此必须发明一种全新技术(例如像MongoDB这样的NoSQL DB)。
有时候，从一系列不完善的选项中，EAV可能是留给您的最佳选择。如果您事先不知道模式是什么，那么EAV可能是您的最佳选择。如果您的架构不重要，则尤其如此。例如，考虑一个在线产品目录，其中有大量的产品列表，每个产品都有一些功能。您无法预先预测哪些产品将具有哪些功能。最后，您对产品功能所做的唯一一件事就是将其转储到“功能:值”列表中。在这种情况下，架构并不是特别强大，因此使用EAV击败架构不会造成特别的破坏。
最重要的是要了解您的设计选择将对您的功能和运营产生什么影响。所有设计都需要权衡。关键是要有意识地进行取舍。与其说“EAV是邪恶的”，不如说:“EAV是一支重炮，请确保您知道它指向的是谁的脚。”
关于c# - 如果EAV是邪恶的，该如何使用动态值？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17231834/