Java Reference
In-Depth Information
because with the single-table strategy, there's only a single table, so bidder and seller data
will be stored in the USERS table together. To tell the data apart, the Bidder class uses
@DiscriminatorValue to configure JPA to store the value "B" in the USERS table
discriminator column USER_TYPE . Seller does the same thing for the value "S"
. Using @DiscriminatorValue is optional, and the default value will be the name
of the class—that is, Seller for the Seller object.
9.5.2. Joined-tables strategy
In the joined-tables strategy, you use a one-to-one relationship between the domain model
and the tables in the database. In effect, the joined-tables strategy involves creating separate
tables for each entity in the domain model. Take a look at figure 9.11 to see how the joined-
tables strategy works.
Figure 9.11. Store all user data using a one-to-one mapping from Java objects to tables.
As figure 9.11 depicts, the USERS table is the parent table and it holds data common to all
users ( USERNAME ). The BIDDERS and SELLERS tables are children of USERS . You can
see that they're children because the USER_ID column in BIDDERS and SELLERS is a
foreign key that points back to the USER_ID column in USERS . The BIDDERS table holds
only bidder-specific data ( BID_FREQUENCY ), whereas the SELLERS table holds seller-
specific data ( CREDIT_WORTH ). These tables have a one-to-one mapping back to the Java
domain model. So the User entity maps to the USERS table, Seller to SELLERS , and
 
Search WWH ::




Custom Search