nhibernate/orm可以支持eav吗？
我最近继承了一个严重依赖 EAV 数据库结构的系统，从性能角度来看确实很困难。
我想要做的是使用 nhibernate 或其他合适的 ORM 产品将这些 EAV 表映射到实体，这样我们就可以将行映射到属性。 然后我们可以重构数据库以使其具有关联性。 有谁知道这是否可能？ 一个例子也将不胜感激！ :)
为了让您感受一下结构，它看起来像这样：
Entity (EntityId) EntityVarchar（EntityId，VarcharValue） EntityFloat(EntityId、VarcharValue)
等。 如果我有一个 Customer 实体，我想说 Customer.Name 来获取名称，而不是 Customer.Varchar["Name"]。
请注意，我们的系统不需要使用 EAV 模型，我们不允许对数据结构进行运行时更改，而且我认为无论如何这是一个不好的做法。
I've recently inherited a system that relies heavily on an EAV database structure, and is really struggling from a performance perspective.
What I want to do is use nhibernate or another suitable ORM product to map these EAV tables to entities in such a way that we can map a row to a property. We can then refactor the database in order to make it relational. Does anyone know if this is possible? An example would also be appreciated! :)
To give you a feel for the structure, it looks something like this:
Entity (EntityId)
EntityVarchar (EntityId, VarcharValue)
EntityFloat (EntityId, VarcharValue)
and so on. If I had a Customer entity I'd like to say Customer.Name to get the name rather than Customer.Varchar["Name"].
Please note there is no need in our system to use an EAV model, we don't allow runtime changes to data structures, and I believe it's a bad practice anyway.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这不会那么容易。 尽管有一些生成器能够读取数据库模式并生成适当的映射和类，但这只会为现有的 eav 数据库生成一个访问层。 要生成此数据库的关系版本，您必须读取数据并创建新的域对象，其中包含数据库中设置的值的属性。
这很可能会产生一个包含 eav 数据库中存在的所有属性的大表。 因此，我认为更好的方法是通过手动分析现有数据并考虑应用程序的需求来创建关系数据库模型。 尤其是表继承应该是你的朋友。
然后，在为两个模式创建访问层后，您仍然需要编写数据迁移的映射。
I don't think this will be that easy. Though there are generators able to read a database schema and generate appropriate mapping and classes this would only result in an access layer for your existing eav db. To generate a relational version of this db you then would have to read the data and create new domain objects containing properties for the the values set in your db.
This could most likely result in one big table containing all the properties exist in the eav db. Therefor I think a better approach would be to create a relational DB model by hand analysing the existing data and considering the needs of your application. Especially Table inheritance should be your friend here.
Then after you have created access layers for both schemas you still would have to write a mapping for data migration.