같은 엔티티에서 일대 다 및 다 대일을 사용할 수 있습니까?

Question

스프링의 나머지 튜토리얼을 수정하고 싶습니다. 링크 here

튜토리얼은 두 기업이있다 : 사용자 및 북마크를 (많은 북마크 한 사용자에 속할 수 있습니다.)

내가 조금 수정하고 싶습니다. 나는 사용자, 질문, 대답 실체를 만들고 싶다 - 사용자는 많은 질문을 가질 수 있고 질문은 많은 대답을 가질 수있다.

이것이 가능합니까? 엔티티 정의가 질문 엔티티에 대해 어떻게 표시되어야합니까?

논리는 사용자가 퀴즈를 만들 수 있다는 것입니다. 퀴즈에는 질문이 포함될 수 있으며 그 질문에는 가능한 답이있을 수 있습니다.

엔티티의 모습 방법을 어떤 아이디어?

나는 모든 아이디어를 고맙게 생각합니다.

Answer 1

Is it possible to use one-to-many and many-to-one in the same entity? 

"질문 엔터티"는 Answers 엔터티와 일대 다 관계를 가질 수 있으며 동시에 User 엔터티와의 다 대일 관계를 가질 수 있다고 가정합니다. 예, 가능합니다. 주석을 사용하여 엔티티를 서로 매핑 할 때주의하십시오. 그렇지 않으면 응용 프로그램의 성능이 심각하게 저하됩니다. eager/lazy fetch를 현명하게 사용하십시오. 후드 아래에서 spring-data-jpa/hibernate가 실행하는 SQL 쿼리를 인쇄하고 분석합니다.

Answer 2

확실히 가능합니다.

사용자

@Entity 
public class User { 

// id and other attributes ommited 

// User and Quiz has OneToMany bidirectional relationship. OP hasn't specified that but I think it makes more sense because a quiz most likely will need to know the user who created it. 
@OneToMany (mappedBy="user", cascade = {CascadeType.PERSIST, CascadeType.REMOVE}) 
private List<Quiz> quizes; 

// ... 
} 

퀴즈

@Entity 
public class Quiz { 
// id ommitted 
@OneToMany 
private List<Question> questions; 

@ManyToOne 
@JoinColumn(name = "user_id") //quiz table will have a column `user_id` foreign key referring to user table's `id` column 
private User user; 

// ... 
} 

질문

@Entity 
public class Question { 
// id ommitted 
@OneToMany 
@JoinColumn(name="question_id") // Question and Answer has one-to-many unidirectional relationship. `answer` table has a foreign key `question_id` referring to `question.id` column 
private List<Answer> answers; 

// ... 
} 

대답

@Entity 
public class Answer { 

// ..more attributes 
} 

참고 :

• 엔티티 관계도 비즈니스 논리에 따라 다릅니다.
• 양방향 관계의 소유자가 다른 경우 클라이언트 코드를 조정해야합니다. jpa-joincolumn-vs-mappedby
• 하나의 엔티티 테이블에 다른 관련 엔티티를 참조하는 외래 키가 없도록 테이블을 "깨끗하게"지정하려는 경우. 조인 테이블을 만들고 OneToMany 관계를 ManyToMany와 같은 "느낌"으로 만들고 고유 인덱스를 사용하여 OneToMany를 시행 할 수 있습니다. 너하기에 달렸다. 이 wikibook page은 꽤 잘 설명합니다.

이것은 절대적으로 유일한 해결책은 아닙니다.