我需要创建数据库,其中Accountgroup表将具有动态字段,以便Accounts可以在需要时输入这些动态字段值.这可能不重要,但我正在使用EF和
Linq的C#.
对我来说很难,因为我从来没有做过这样的事情,而且自从我做研究以来,每个人都在说EAV系统是可怕的,你应该设计不同,问题是没有人会告诉他们 – 怎么样？
所以也许你可以帮助我,告诉我如何在不做EAV的情况下实现类似的事情？
这是我到目前为止.
解决方法
经验法则的问题在于,他们很快就从“通过X做错”到“永不做X”.
EAV通常是一个坏主意,因为在许多方面,它会破坏关系模式的目的,从而消除了关系型数据库管理系统的许多特性和优点,以及建立在RDBMS上的其他技术,如像实体框架这样的ORM.
然而,RDBMS不是很适合的一些设计问题.有一些这样的坏配合,必须发明一种全新的技术(例如Nosql DB,如MongoDB).
有时EAV可能是您从一组不完美的选择中留下的最佳选择.如果您不能(不能)知道您的模式是否在手,那么EAV可能是您的最佳选择.如果您的模式变得不重要,这一点尤其如此.考虑一个在线产品目录,其中有一个巨大的产品列表,每个产品都有一些功能.您无法预先预测哪些产品将具有哪些功能.最后,您只能使用产品功能将其转储到“feature：value”列表中.这是一种模式不是特别强大的情况,所以用EAV打败它并不是特别有害的.
最重要的是了解您的设计选择将对您的能力和运营做些什么.所有的设计是权衡的.关键是要有意识地取舍.而不是“EAV是邪恶的”,而是考虑：“EAV是一个加载的枪,确保你知道你指向的脚.”
