Оставляя «однонаправленным» на данный момент в стороне, можно смоделировать отношения Заказ-Заказчик следующим образом.
@Entity
public class Customer {
// ...
@Id @GeneratedValue
int id;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "customer")
Set<Order> orders;
// ...
}
@Entity
public class Order {
// ...
@ManyToOne(optional = false)
Customer customer;
// ...
}
Здесь я предполагаю, что в каждом Заказе есть ровно один Клиент.В базе данных таблица заказов будет иметь столбец customer_id с внешним ключом столбца id таблицы Customer.DDL будет выглядеть примерно так:
CREATE TABLE Customer (
id INT NOT NULL,
...
PRIMARY KEY (id)
);
CREATE TABLE Order (
...
customer_id INT NOT NULL,
...
FOREIGN KEY (customer_id) REFERENCES Customer (id)
);
Хотя класс Customer содержит коллекцию заказов, на самом деле это никак не влияет на структуру базы данных;это просто удобный способ получения / управления заказами, принадлежащими клиенту.Например, вы можете полностью удалить элемент "orders" из Customer и полагаться на запросы для извлечения этих записей.
Я хочу подчеркнуть, что с точки зрения базы данных , действительно нет такой вещи, как "однонаправленные" отношения.Приведенный пример reverendgreen создаст классы Java, где нет прямого способа получить объект Customer из объекта Order, но результирующая структура базы данных будет идентична (игнорируя незначительные различия в столбцеимена).Вы всегда можете найти клиента для данного заказа с помощью запроса.