JOINED 상속 전략을 EclipseLink JPA 구현과 함께 사용하고 있습니다. 나는 이클립스 링크가 데이터베이스 스키마에 디폴트 DTYPE에 의해 명명 된 discriminator 칼럼을 추가하고있는 것을 보았다. 그 판별자가 하나의 테이블 상속 전략에 필요하다는 것을 이해합니다. 그러나 왜 JOINED 전략을 사용해야합니까?왜 EclipseLink가 결합 된 상속 전략을위한 판별 자 열을 추가합니까?
제거한 후에 오류가 발생하여 EclipseLink에이 열이 필요합니다. 성능상의 이유로이 칼럼이 추가 되었습니까? 나는 데이터베이스 스키마의 관점에서 볼 때이 컬럼이 불필요하게 혼란 스럽기 때문에 그다지 행복하지 않다.
Hibernate 기반 JPA는 비슷한 것을하지 않습니다. Joined Table Inheritance에서
: 조인 된 테이블 상속에서
, 루트 테이블에서 각 클래스 데이터를 공유합니다. 또한 각 서브 클래스는 확장 된 상태를 추가하는 자신의 테이블을 정의합니다.
...
판별 열이 테이블을 접합 어떤 따라서 유형을 판정하고, 어떤 경우 : 다음의 예는뿐만 아니라 두 테이블 프로젝트 L_PROJECT, 두 같은 클래스, 프로젝트 및 LargeProject를 도시 사용하려면 부모 테이블에 판별 자 열이 있어야합니다.
정확히, 그리고 이것이 제가 이해하고자하는 것입니다 : 왜 이클립스가이 discriminator 컬럼을 사용하는지 - JOINED 전략은 외래 키 연관성을 기반으로합니다. 수업. JPA 스펙에서는 JOINED 전략에 대한 판별자가 선택적이라고 말합니다. Hibernate JPA는이를 사용하지 않습니다. EclipseLink에서와 같이이를 사용하면 어떤 이점이 있는지 배우고 싶습니다. –
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tablepersubclass를 언급 한 것 같습니다. ExlipseLink 나는이 점에 대해서 명시 적으로 추측합니다. discriminator 열은 EXISTS (또는 비슷한) 검사를 수행하여 적절한 하위 클래스를 찾는 문제를 방지합니다. 그것이 선택 사항이라 할지라도 나는 그것을 여전히 사용하고 있습니다. – cletus
그건 틀림없이, discriminator는 확실하게 일을 쉽게 구현합니다. 답변 해줘서 고마워! –
아마도 질문에 오류가 발생했을 수 있습니다. 당신은 JOINED가 아니라 JOINED 인 이유를 이해한다고 말합니다 ... – cletus