为什么在带有“设置”字段的情况下使用Hibernate的示例未在数据库表中声明外键？

Question

This link gives an example of how to use Hibernate with classes with Set fields.

The following is the part for defining the corresponding database tables in MySQL:

Define RDBMS Tables Consider a situation where we need to store our employee records in EMPLOYEE table, which would have the following structure −

 create table EMPLOYEE ( id INT NOT NULL auto_increment, first_name VARCHAR(20) default NULL, last_name VARCHAR(20) default NULL, salary INT default NULL, PRIMARY KEY (id) ); 

Further, assume each employee can have one or more certificate associated with him/her. So, we will store certificate related information in a separate table having the following structure −

 create table CERTIFICATE ( id INT NOT NULL auto_increment, certificate_name VARCHAR(30) default NULL, employee_id INT default NULL, PRIMARY KEY (id) ); 

There will be one-to-many relationship between EMPLOYEE and CERTIFICATE objects

I was wondering why it does not declare employee_id of CERTIFICATE as a foreign key to the primary key id of table EMPLOYEE in MySQL?

Thanks.

Answer 1

Normally, applications that use an Object-Relationship Mapping (ORM) framework, such as hibernate, handle all the relationship logic themselves (ie cardinality, constraints, ect..). So it is possible that, as far as the database concerns, employee_id is just a single number that has no relationship with any other table, and, on the other hand, Hibernate considers it as a foreign key to the Employee table. In this case, Hibernate would be the one in charge of managing all the relationship logic.

The advantage of this approach is that you can create certificates that are not associated to any employees at the database level. Let's say that you are migrating data to a database, and you migrate first all the certificate's table. If you had enforced the foreign key constraint, you couldn't do that: you would have to first migrate the employees' table and THEN the certificates one. However, by following the tutorial on the link you posted, you wouldn't need to worry about this, because you can have certificates belonging "fake" employees. This would happen in an intermediate transient state when you're not done migrating all your data.