До сих пор я исходил из того, что сущность будет отображаться в одну таблицу, также известную как
@Entity
@SecondaryTables({
··@SecondaryTable(name = "city"),
··
@SecondaryTable(name = "country")
})
public class Address {
··@Id
··private Long id;
··private String street1;
··private String street2;
··@Column(table = "city")
··private String city;
··@Column(table = "city")
··private String state;
··@Column(table = "city")
··private String zipcode;
··@Column(table = "country")
··private String country;
··// Конструкторы, геттеры, сеттеры
}
По умолчанию атрибуты сущности Address будут отображаться в первичную таблицу (которая по умолчанию имеет имя сущности, поэтому называется ADDRESS). Аннотация @SecondaryTables проинформирует вас о том, что в данном случае есть две вторичные таблицы: CITY и COUNTRY. Затем вам потребуется указать, какой атрибут в какой таблице будет располагаться (с использованием аннотации @Column(table="city") или @Column(table="country")). На рис. 5.1 показана структура таблиц, в которых будет отображаться сущность Address. Каждая таблица содержит разные атрибуты, однако у всех имеется один и тот же первичный ключ (для соединения таблиц). Опять-таки не забывайте, что Derby преобразует имена таблиц в нижнем регистре (city) в имена таблиц в верхнем регистре (CITY).
Рис. 5.1. Сущность Address отображается в трех таблицах
Как вы, вероятно, уже поняли, для одной и той же сущности может быть несколько аннотаций. Если вы захотите переименовать первичную таблицу, то можете добавить аннотацию @Table, как показано в листинге 5.3.
@Entity
@Table(name = "t_address")
@SecondaryTables({
··@SecondaryTable(name = "t_city"),
··@SecondaryTable(name = "t_country")
})
public class Address {
··// Атрибуты, конструктор, геттеры, сеттеры
}
При использовании вторичных таблиц вы должны принимать во внимание производительность. Каждый раз, когда вы получаете доступ к сущности, поставщик постоянства обращается к нескольким таблицам, которые ему приходится соединять. С другой стороны, вторичные таблицы могут оказаться кстати, когда у вас имеются «затратные» атрибуты вроде больших двоичных объектов (Binary Large Object — BLOB), которые вы хотите изолировать в другой таблице.