可以说我有以下表格:
TASKS:
task_id (INT) (PK)
staff_id (VARCHAR) (FK)
task_name (VARCHAR)
EMPLOYEE:
employee_id (INT) (PK)
employee_name (VARCHAR)
department_name (VARCHAR)
CONTRACTOR:
contractor_id (VARCHAR) (PK)
contractor_name (VARCHAR)
agency_name (VARCHAR)
other_field (VARCHAR)
我需要在EMPLOYEE和TASK之间建立一对多关系,在CONTRACTOR和TASK之间建立一对多关系,并在TASK和EMPLOYEE之间以及与TASK和CONTRACTOR之间建立对应的多对一关系。
>需要在staff_id外键上创建关系。我面临的挑战是Employee和Contractor实体不共享相同的主键,并且这些键具有不同的名称,并且它们的键具有不同的类型。
我的第一个问题是是否可以使用不同类型的键在表之间实现关系? (我认为不是,但是我正在尝试遵循其他人的规范。)
第二个问题,在JPA中表达这种关系的正确方法是什么?我这是什么:
任务实体
@Id
@Column(name = "task_id", columnDefinition = "INT(11)")
private Long taskId;
@Id
@Column(name = "staff_id" columnDefinition = "VARCHAR(50)")
private String staffId;
@Column(name = "task_name", columnDefinition = "VARCHAR(250)")
private String taskName;
@MapsId("task_id")
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "staff_id") <------- what should this value be ??
private Staff staff;
工作人员界面:
public interface Staff {
}
员工实体:
class Employee implements Staff {
@Id
@Column(name = "employee_id", columnDefinition = "INT(11)")
private Long employeeId;
@Column(name = "employee_name", columnDefinition = "VARCHAR(50)")
private String employeeName;
@Column(name = "department_name", columnDefinition = "VARCHAR(50)")
private String departmentName;
@OneToMany(fetch = FetchType.EAGER, mappedBy="staff")
private List<Task> tasks = new ArrayList<Task>();
}
承包商实体
class Contractor implements Staff {
@Id
@Column(name = "contractor_id", columnDefinition = "INT(11)")
private Long contractorId;
@Column(name = "contractor_name", columnDefinition = "VARCHAR(50)")
private String contractorName;
@Column(name = "agency_name", columnDefinition = "VARCHAR(50)")
private String agencyName;
@Column(name = "other_field", columnDefinition = "VARCHAR(50)")
private String otherField;
@OneToMany(fetch = FetchType.EAGER, mappedBy="staff")
private List<Task> tasks = new ArrayList<Task>();
}
我不知道在ManyToOne端的@JoinColumn批注中使用什么列名:两个实体都不包含“ staff_id”字段。我想到了在Staff界面中创建此类字段,然后以编程方式将其中两个ID的值分配给staff_id的方法,但这似乎不是正确的方法。
任何建议都值得赞赏。