Feature/apply schema

[yesinkim]

이전

현재

큰 구조를 그대로 두되 중복컬럼을 고려해 application Table을 하나로 통일하였습니다.

[mksoo]

❓그럼 apllication에 러너, 빌더 지원 내용들이 다 들어가는 건가요? 그렇게 되면 learner-academy 테이블은 어떻게 되는걸까용
❓ 그리고 form_type은 뭘까용?

[yesinkim]

@mksoo

❓그럼 apllication에 러너, 빌더 지원 내용들이 다 들어가는 건가요? 그렇게 되면 learner-academy 테이블은 어떻게 되는걸까용
=> 초기 구조에 러너지원서, 빌더 지원서 테이블을 구분했는 데 컬럼이 똑같아서 form_type(구 division)으로 구분을 하면 필터링할 수 있을 것 같아 통합했습니다. 혹시 제가 놓친 사이드 이펙트가 있을 수 있으니 알려주시면 감사할 것 같습니다!
그리고 learner academy는 learner와 academy 관계를 알수 있는 테이블이 없다고 생각해 서브테이블을 생성했습니다. 빌더랑 애플리케이션을 연결하는 테이블은 academy 테이블이라고 생각하시면 될 것 같습니다.

❓ 그리고 form_type은 뭘까용?
=> 기존 division을 추가 확장성이나 이름의 명확성을 고려해 form_type으로 변경하고 추가 설명 달아두었습니다.
int 로 1: builder, 2: learner 로 생각하고 있습니다.

[mksoo]

💊음 사이드 이펙트까진 아니지만, 그렇게 되면 application 테이블에서 러너나 빌더 조회할 때 user_id + form_type으로 조합해서 조회해야 겠다고 생각이 드네용! 그래도 상관 없을 것 같긴 합니당.
💊그리고 application에서 academy id도 같이 참조하면 어떨가요? 어떤 academy에 apply 했는지 알면 좋을 것 같네요!
❓user_id도 그림에는 안나와 있지만 user table을 참조하는 거죠!?
💊음 그리고 그렇게 되면 is_completed도 그냥 nullable로 application에 들어가도 될 것 같긴 한데, 합쳐도 그만 안해도 그만일 것 같아서 예신님 편하신대로 하시면 될 것 같아용

[yesinkim]

@mksoo 광수님 꼼꼼히 살펴서 리뷰해주셔서 감사합니다 !! :)
말씀해주신 내용 고려해서 이 PR은 apply CRUD 작업까지 같이 올려볼게요!!
(우선은 draft로 변경해두었습니다)

그리고 말씀하신 것처럼 모든 user_id는 user table을 참조하는 외래키입니다.