У меня три таблицы, которые представляют мой очень простой проект.
CREATE TABLE company (
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(250) NOT NULL
);
CREATE TABLE employee (
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(250) NOT NULL
);
CREATE TABLE company_employee (
company_id INT NOT NULL,
employee_id INT NOT NULL,
hire_date DATE DEFAULT NULL,
resign_date DATE DEFAULT NULL,
FOREIGN KEY (company_id) REFERENCES company (id),
FOREIGN KEY (employee_id) REFERENCES employee (id)
);
И у меня есть представление Java
@Entity
@Table(name = "employee")
public class Employee implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
Integer id;
@Column(name = "name")
String name;
@ManyToMany(mappedBy = "employees")
private List<Company> companies;
@Entity
@Table(name = "company")
public class Company implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Integer id;
@Column(name = "name")
private String name;
@ManyToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL)
@JoinTable(name = "company_employee",
joinColumns = {@JoinColumn(name = "company_id")},
inverseJoinColumns = {@JoinColumn(name = "employee_id")})
private Collection<Employee> employees;
Я не могу понять, где я могу хранить данные истории. В данных истории мне нужно хранить lease_date, resign_date от emplyee и хранить все компании каждого emplyee. Итак, мой вопрос: могу ли я управлять такой информацией и как лучше всего хранить всю эту историю?
Это отношение многих к многим с атрибутами. Я уверен, что вы сможете понять, с кем справиться с одним основным примером:
http://www.mkyong.com/hibernate/hibernate-many-to-many-example-join-table-extra-column-annotation/
У вас уже есть таблица пересечений "company_employee".
Вы можете сохранить здесь employee1 1.1.2013 до 31.12.2013 @company1. И в другое время 1.1.2014... 31.12.2014 @company2.
Вы должны заказать по адресу rent_date desc. В случае дефиниции первое значение в списке - текущее или последнее занятие, а все остальные - как история.
Это не вопрос того, где хранить, но как читать данные.