최대 지망 수를 동적으로 관리하기 위한 방법

[whqtker]

현 상황

@Column(nullable = false, name = "first_choice_university_info_for_apply_id")
privatelongfirstChoiceUnivApplyInfoId;
@Column(name = "second_choice_university_info_for_apply_id")
privateLongsecondChoiceUnivApplyInfoId;
@Column(name = "third_choice_university_info_for_apply_id")
privateLongthirdChoiceUnivApplyInfoId;

현재는 모든 출신 대학에 대해서 최대 3지망까지 지원 가능하도록 강제하고 있습니다.

경희대같은 경우 최대 5지망까지 지원 가능합니다.

따라서 출신 대학별로 가능한 최대 지원 수를 관리해야 합니다.

n지망 모의지원을 어디에 저장할 것인가

기존 방식입니다. application 테이블

별도 클래스 분리

CREATETABLEapplication_choice (
id BIGINTPRIMARY KEY AUTO_INCREMENT,
application_id BIGINTNOT NULL,
choice_order INTNOT NULL, -- n지망
univ_apply_info_id BIGINTNOT NULL,
);

1. @Entity
2. @ElementCollection

• 소유한 엔티티 없이 단독으로 조회 및 수정되지 않을 때
• @Embeddable과 마찬가지로 PK 없음
• 소유 엔티티가 삭제되면 같이 삭제됨
• 별도 테이블을 가짐. 이때 FK는 소유한 엔티티의 PK가 됨
• JPA가 해당 테이블의 행들은 소유한 엔티티 데이터 일부로 취급함

3. @Embeddable

• 소유한 엔티티가 삭제되면 같이 삭제됨

일반적으로 데이터가 다른 엔티티에서도 참조되면 @Entity (생명주기가 독립적이라면)
그렇지 않은 경우 (생명주기가 소유한 엔티티에 속한다면) 컬렉션이라면 @ElementCollection, 그렇지 않다면 @Embeddable을 사용하는 것 같습니다.

@ElementCollection 과 @Embeddable의 가장 큰 차이점은 별도의 테이블이 생기냐, 코드에서 이들을 어떻게 관리하냐 정도인 거 같습니다.

최대 지망 수를 어디에 저장할 것인가

home_university에

maxChoiceCount 같은 컬럼 추가
만약 학기별로 최대 지원 수가 달라진다면 추가 작업 필요

(term, home_university) 조합

CREATETABLEterm_home_university (
term_id BIGINTNOT NULL,
home_university_id BIGINTNOT NULL,
max_choice_count INTNOT NULL,
PRIMARY KEY (term_id, home_university_id)
);

매 지원 시기마다 데이터 넣어줘야 함

[Hexeong]

고생하십니다! 아래 의견 적어두겠습니다!

1. n 지망 정보에 대해서는 별도 테이블(연관테이블) 방식을 사용하는 것에 대해서도 찬성입니다! 저는 @embeddable을 쓰면 3지망이라고 할때 record가 3개가 추가되는 방식이 되는 걸로 알아서 저희 application 필드가 많은 만큼 단점이 되지 않을까 싶습니다..

2. 컬럼 추가 동의합니다! 개인적으로 학교의 정책 변경으로 인해 값 수정이 필요할 수 있으니, admin이 변경 가능하게 따로 API를 추가하면 운영상 도움이 될 것 같습니다!

[sukangpunch]

1. @ElementCollection 활용이 깔끔할 것 같습니다.
2. HomeUnviersity 에 컬럼 추가 하는 것이 좋은 것 같습니다!
   많은 학교들이 고정된 지망 수를 정책으로 하지 않을 까 싶습니다.

[whqtker]

결정 사항입니다.

1. 최대 지망 수는 home_university에 필드에 저장한다.
2. n지망 지원 수는 @ElementCollection 방식