Java Reference
In-Depth Information
Table 7-21.
The
Entity
Table
ID
Name
1
Entity 1
A separate collection table, on the other hand, contains the actual values (see Table 7-22).
In this case, we are linking a
List
to the owning entity, so we need to include a column to rep-
resent the position of the values in the list, as well as the foreign key into the owning entity
and the column for the actual values that are contained within the collection.
Table 7-22.
ListTable
entityid
positionInList
listValue
1
1
Good
1
2
Bad
1
3
Indifferent
In a legacy schema, you may quite often encounter a situation in which all the values
have been retained within a single table (see Table 7-23).
Table 7-23.
EntityTable
ID
Name
positionInList
listValue
1
Entity 1
1
Good
1
Entity 1
2
Bad
1
Entity 1
3
Indifferent
It should be obvious that this is not just poor design from Hibernate's perspective—it's
also bad relational design. The values in the entity's
name
attribute have been duplicated need-
lessly, so this is not a properly normalized table. We also break the foreign key of the table, and
need to form a compound key of
id
and
positionInList
. Overall, this is a poor design, and we
encourage you to use a second table if at all possible. If you must work with such an existing
design, see Chapter 13 for some techniques for approaching this type of problem.
If your collection is going to contain entity types instead of value types, the approach is
essentially the same, but your second table will contain keys into the second entity table
instead of value types. This changes the combination of tables into the situation shown in the
entity relationship diagram (see Figure 7-4), in which we have a link table joining two major
tables into a many-to-many relationship. This is a very familiar pattern in properly normal-
ized relational schemas.
The following code shows a mapping of a
Set
attribute representing the adverts with
which the
User
class is associated:
Search WWH ::
Custom Search