Any real use for a table for a particular class with implicit polymorphism?

Question

If matching inheritance using a table for a particular class, when matching specific classes, is just like any other class (without subclassing), NHibernate allows the same PK for subclasses. For example, if you have BillingDetails and subclasses of CreditCard and BankAccount, a query for all BillingDetails will give you all the records from both tables, which, in turn, may have duplicate primary keys, which can be problematic due to the invalid business identity of these objects. This, of course, does not apply to guides and the like, but what about cases with the same identifiers or sequence identifier generators?

Just the question is, is there a real use of duplicate key keys in this scenario when requesting such a polymorphic request? Can these duplicate identifiers cause problems for NHibernate when working with objects inside?

Answer 1

Implicit polymorphism is necessary when comparing legacy models in which tables do not have a common key.

There is no problem getting a BillingDetails list with CreditCard and BankAccount instances using the same identifier because NH knows they are unrelated (and they are treated as referring only to the goals of the request, by running one request for each matching subclass)

You should not use it to develop a new field.