Java Reference
In-Depth Information
9.5.3. Table-per-class strategy
In the table-per-class strategy, each entity in the domain model gets its own table similar to
the joined-tables strategy, but the big difference between the two strategies is that there's
no relationship between the tables in the table-per-class strategy. All of the shared data of
the joined-tables strategy isn't shared in the table-per-class strategy and is instead duplic-
ated in each table. Take a look at
figure 9.12
to see how the table-per-class strategy works.
Figure 9.12. Table-per-class strategy database tables with duplicate data
Looking at
figure 9.12
,
you quickly see the difference in the table-per-class strategy. As
before, the
User
entity maps to the
USERS
table,
Seller
to
SELLERS
, and
Bidder
to
BIDDERS
. But this strategy doesn't take advantage of the power of relational databases at
all. The tables have no relationships among them so they're unable to share data. Conse-
quently, shared data like
USER_ID
and
USERNAME
are duplicated in each table.
Because of the duplication of data, you have to be careful when saving data with the
table-per-class strategy, especially if that data needs to be unique like the
USER_ID
and
USERNAME
columns. The data needs to be unique not only in the “child” table but in the
“parent” table as well (“parent” and “child” are in quotes because no real relationship exists
between the tables). For example, suppose you want to save a new bidder and this new bid-
der has the following data:
USER_ID = 10
,
USERNAME = "ActionBazaarUser-
123"
. These values may be unique in the
BIDDERS
table, but with the table-per-class
strategy, the data will also be saved in the
USERS
table. In the
USERS
table, these values
may not be unique because a seller may have already used them.
