계층 구조 보존 전략 선택

설명

위의 각 전략과 기술에는 고유한 장점과 단점이 있습니다. 특정 전략을 선택하기 위한 일반적인 권장 사항은 다음과 같습니다.

UNION 기반 TABLE_PER_CLASS 전략

이 전략은 다형성 쿼리 및 연결이 필요하지 않은 경우에 선택하는 것이 가장 좋습니다. 거의 수행하지 않는 경우(또는 전혀 수행하지 않는 경우) "사용자 사용자에서 사용자 선택". User를 참조하는 Entity 클래스가 없는 경우 이것이 최선의 옵션입니다(여전히 최적화된 다형성 쿼리 및 연결을 추가할 수 있으므로).

SINGLE_TABLE 전략

이 전략을 사용해야 합니다.

a) 단순한 작업에만 해당됩니다. 정규화 및 NOT NULL 제약 조건이 중요한 상황에서는 전략 #3(JOINED)을 선호해야 합니다. 이 경우 상속을 완전히 포기하고 위임으로 대체할 가치가 없는지 생각하는 것이 이치에 맞습니다.

b) 런타임에 구체적인 클래스의 동적 정의뿐만 아니라 다형성 쿼리 및 연결이 필요한 경우. 동시에 하위 클래스는 비교적 적은 수의 새 필드를 선언하며 상위 클래스와의 주요 차이점은 동작에 있습니다.

게다가 DBA와 진지한 대화를 나눴습니다.

조인 전략

이 전략은 속도와 제약 측면에서 가장 효율적입니다. 다형성 쿼리 및 연결이 필요한 경우에 적합하지만 하위 클래스는 비교적 많은 새 필드를 선언합니다.

여기서 주의 사항: JOINED와 TABLE_PER_CLASS 사이의 결정에는 실제 데이터에 대한 쿼리 실행 계획의 평가가 필요합니다. 상속 계층 구조의 너비와 깊이로 인해 조인 비용(및 결과적으로 성능)이 허용되지 않을 수 있기 때문입니다.

이와는 별도로 상속 주석을 인터페이스에 적용할 수 없다는 점을 고려해야 합니다.

명백한

데이터베이스에 공유 스토리지 전략이 있는 엔티티 클래스의 계층 구조가 있는 상황도 있을 수 있습니다. 그러나 어떤 이유로든 기본 클래스에서 쿼리가 수행될 때 일부 계층 구조 클래스가 반환되는 것을 원하지 않습니다.

이에 대한 주석이 있습니다.

@Polymorphism(type = PolymorphismType.EXPLICIT)

클라이언트 클래스 에 추가하면 다음과 같습니다 .

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
class User {
  int id;
  String name;
  LocalDate birthday;
}

@Entity
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}

@Entity
@Polymorphism(type = PolymorphismType.EXPLICIT)
class Client extends User {
   String address;
}

그런 다음 HQL 쿼리는 기본 클래스를 쿼리할 때 이 클래스의 개체를 무시합니다.

List<User> accounts = session.createQuery("from User").getResultList();

이 쿼리는 User 및 Employee 개체 목록을 반환 하지만 Client는 반환하지 않습니다 .