the three strategies:
[list]
[*]table per class hierarchy
[*]table per subclass
[*]table per concrete class
[/list]
[b]1.Table per class hierarchy[/b]
Suppose we have an interface Payment with the implementors CreditCardPayment and CashPayment. The table per class hierarchy mapping would display in the following way:
Exactly one table is required. There is one limitation of this mapping:columns declared by the subclass cannot have [i]not null [/i]constraints.
[list]
[*]table per class hierarchy
[*]table per subclass
[*]table per concrete class
[/list]
[b]1.Table per class hierarchy[/b]
Suppose we have an interface Payment with the implementors CreditCardPayment and CashPayment. The table per class hierarchy mapping would display in the following way:
<class name="Payment" table="PAYMENT">
<id name="id" type="long" column="PAYMENT_ID">
<generator class="native"/>
</id>
<discriminator column="PAYMENT_TYPE" type="string"/>
<property name="amount" column="AMOUNT"/>
...
<subclass name="CreditCardPayment" discriminator-value="CREDIT">
<property name="creditCardType" column="CCTYPE"/>
...
</subclass>
<subclass name="CashPayment" discriminator-value="CASH">
...
</subclass>
</class>
Exactly one table is required. There is one limitation of this mapping:columns declared by the subclass cannot have [i]not null [/i]constraints.
本文介绍了三种常见的对象关系映射(ORM)策略:按类层次结构表(Table per class hierarchy)、按子类表(Table per subclass)及按具体类表(Table per concrete class)。以支付接口为例,展示了按类层次结构表的具体实现方式及其限制。
4820

被折叠的 条评论
为什么被折叠?



