Overview of persisting a domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 106

The main drawback of this approach is that it requires multiple SQL statements to
update and delete entities. It also requires SQL statements to use multiway joins.
For example, when the application creates a FreeShippingCoupon , it must insert a
row into the COUPON and FREE_SHIPPING_COUPON tables; when it loads a Cou-
pon , it must either use a SQL SELECT statement that does a join with all three tables
or execute multiple SELECT statements.

Table per concrete class
The third and final option is to define a table for each concrete class, that is, each
class that is not an abstract class or an interface. In the Coupon hierarchy example,
we define the tables for the PercentageDiscountCoupon and FreeShippingCoupon
classes:

CREATE TABLE PERCENT_DISCOUNT_COUPON (
COUPON_ID NUMBER(10) NOT NULL,
CODE VARCHAR2(30) NOT NULL,
MINIMUM NUMBER(10,2) NOT NULL,
DISCOUNT_PERCENTAGE NUMBER(5,2),
CONSTRAINT COUPON_PK
PRIMARY KEY(COUPON_ID),
)

CREATE TABLE FREE_SHIPPING_COUPON (
COUPON_ID NUMBER(10) NOT NULL,
CODE VARCHAR2(30) NOT NULL,
MINIMUM NUMBER(10,2) NOT NULL,
CONSTRAINT COUPON_PK
PRIMARY KEY(COUPON_ID)
)
Each table has columns corresponding to fields for the class and its superclasses.
This approach has the following benefits:

Creating or saving instances only requires a single INSERT or UPDATE state-
ment.

■

There are no unused columns, and the application can define the correct
constraints.

■

There are, however, numerous drawbacks:

References to a superclass are difficult to map to the database schema. For
example, in order to represent the PendingOrder - Coupon relationship,
PENDING_ORDER would need foreign keys to the PERCENT_DISCOUNT
_COUPON and FREE_SHIPPING_COUPON tables.

■