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

Each time we define a new subclass that requires new columns, we must
modify this table.

■

Table per class
If you want to avoid those problems, you can instead map each class to its own
table. In this example we use three coupon tables, one for each class:

CREATE TABLE COUPON (
COUPON_ID NUMBER(10) NOT NULL,
CODE VARCHAR2(30) NOT NULL,
COUPON_TYPE VARCHAR2(100) NOT NULL,
MINIMUM NUMBER(10,2) NOT NULL,
);

CREATE TABLE PERCENT_DISCOUNT_COUPON (
COUPON_ID NUMBER(10) NOT NULL,
DISCOUNT_PERCENTAGE NUMBER(5,2),
CONSTRAINT COUPON_PK
PRIMARY KEY(COUPON_ID),
CONSTRAINT PERCENT_DISCOUNT_COUPON_FK
FOREIGN KEY(COUPON_ID)
REFERENCES COUPON(COUPON_ID)
);

CREATE TABLE FREE_SHIPPING_COUPON (
COUPON_ID NUMBER(10) NOT NULL,
CONSTRAINT COUPON_PK
PRIMARY KEY(COUPON_ID)
CONSTRAINT FREE_SHIPPING_COUPON_FK
FOREIGN KEY(COUPON_ID)
REFERENCES COUPON(COUPON_ID)
);
The COUPON table contains a row for each coupon. The PERCENT_DISCOUNT
table contains the percentage discount coupons and its primary key column,
COUPON_ID , is a foreign key to the COUPON table. Similarly, the FREE_SHIP-
PING_COUPON table contains the free shipping coupons and its primary key is
also a foreign key to the COUPON table.
This approach has the following benefits:

It does not result in unused columns, which minimizes space utilization and
enables columns, such as DISCOUNT_PERCENTAGE , to have the appropriate NOT
NULL definition.

■

References to a superclass are simply mapped to a foreign key reference to
a single table.

■

It enables new subclasses to be added without having to modify existing tables.

■