繼承選擇策略，一下是一些經驗法則：
- 如果你不需要多態關聯或者查詢，就傾向於每個具體類一張表——換句話說，如果你從不或者很少查詢BillingDetails,並且沒有關聯BillingDetails的類。基於UNION的顯式映射應該是首選，因爲隨後（最優化的）多態查詢和關聯將成爲可能。隱式多態對於利用非持久化相關的接口的查詢最有用。
- 如果你一定要多態關聯（對超類的關聯，及由此在運行時通過具體類的動態解析對層次結構中所有類的關聯）或者查詢，並且子類相對地聲明幾種屬性（尤其當子類之間的主要區別在於它們的行爲中）時，則傾向於每個類層次結構一張表。你的目標是把可爲空的列數減到最少，並讓你自己（和數據庫管理員）確信反規範化的Schema在長期運行中不會產生問題。
- 如果你一定需要多態的關聯或者查詢，並且子類聲明多個屬性（子類的不同主要在於它們所持有的數據），則傾向每個子類一張表。或者，根據繼承層次結構的寬度和深度，以及想對於聯合的可能聯結成本，使每個具體類一張表。
默認情況下，僅對簡單的問題選擇每個類層次結構一張表。對於更復雜的案例（或者當你被一位堅持認爲可爲空的能力約束和標準化很重要的數據建模者否決的時候），就應該考慮每個子類一張表的策略。但這時候要問問自己：在對象模型中，重新把繼承建模爲委託是否未必更好。對於無關持久化或者ORM的各種原因，通常最好避免複雜的繼承。Hibernate充當着領域和關係模型之間的緩衝區，但這並不意味着在設計類的時候，可以忽略持久化關注點。
當你開始考慮混合的繼承策略時，記住：HIbernate中的隱式多態很聰明，足以處理更多異乎尋常的情況。例如，在考慮在應用程序中增加一個接口ElectronicPaymentOption。這是一個沒有持久化方面的業務接口——除了在我們的應用程序中，例如CreditCard這樣的持久化類將可能實現這個接口之外。無論你如何映射BillingDetails層次結構，Hibernate都可以正確地給from ElectronicPaymentOption回覆查詢。甚至不是BillingDetails層次結構一部分的其他類也可以，它們被映射爲持久化，並實現這個接口。Hibernate始終知道要查詢哪些表、構造哪些實例，以及如何返回一個多態的結果。
最後，也可以在單個的映射文件中使用<union-subclass>、<subclass>、和<joined-subclass>映射元素（作爲一級元素，而不是<class>）。然後必須聲明被擴展的類，例如<subclass name="CreditCard" extends="BillingDetails">，且必須在子類映射文件之前程序化地加載其類映射（在XML配置文件中列出映射資源清單時，不必擔心這個順序）。這種技術允許擴展類層次結構，而不用修改超類的映射文件。