Any real use for table-per-concrete-class with implicit polymorphism?

浪子不回头ぞ 提交于 2020-01-24 14:05:09

问题


If mapping inheritance using table per concrete class, while mapping concrete classes simply just as any other class (without union-subclass), NHibernate allows same PKs across subclasses. For example if you have BillingDetails and subclasses CreditCard and BankAccount, requesting all BillingDetails will get you all records from both tables, which can in turn have duplicate primary keys, which can be problematic due to not valid business identity of those objects. This of course is not the case with guids and such, but what about cases of plain identity or sequence id generators?

Simply, the question is, is there any real use of this scenarion of duplicate id keys when requesting polymorphic query like that? Could these duplicate ids make problems for NHibernate when handling entities internally?


回答1:


Implicit polymorphism is necessary when mapping legacy models where the tables do not share a common key.

There are no problems with getting a list of BillingDetails with CreditCard and BankAccount instances sharing the same Id, because NH knows they are unrelated (and they are treated as related only for the purposes of querying, by running one query for each mapped subclass)

You should not use it for greenfield development.



来源:https://stackoverflow.com/questions/9097933/any-real-use-for-table-per-concrete-class-with-implicit-polymorphism

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!