TIL-211028

1. 에어비앤비 클론코딩 데이터베이스

• 숙소의 옵션(2가지 종류)을 @Embedded @Embeddable로 관리할지
• 따로 테이블로 관리할지
  • 1) 모든 옵션을 칼럼으로 갖는 옵션 table을 숙소 table이 참조하고, 각 옵션이 있으면 해당 필드에 1, 없으면 0을 저장
  • 2) 옵션 유무 조합(2^n) table을 만들고 숙소 table이 참조
• 1,2안의 문제
  • 1안
    • 없는 정보를 굳이 표현(공간을 차지)하고 있다
    • column 변경시 alter table의 비용
  • 2안
    • column이 변경되면 row가 변경되고(column 1개 추가시 record 2배로 증가 + 숙소 테이블과 재 mapping) -> 비용이 매우 큼
    • 마찬가지로 column 변경시 alter table의 비용(table을 새로 만들고 기존 정보를 변경된 column과 함께 재삽입 해야 할수도 있음)
• 대안
  • roomId, option(enum:VARCHAR)
    2개의 column을 갖는 option 테이블을 두고, room 레코드 삽입시 option 테이블에 roomId와 option을 삽입
  • 보유한 option 정보만 가지고, 없는 option은 table에 없음
  • option 추가, 도는 option명 변경시 비용이 1,2안 보다 적음
    • column을 추가/ column 명 수정으로 alter table을 하지 않고, field와 mapping되는 enum class에 값 추가/field값 변경으로 해결 가능하다

2. Github : issue 기반 branch 생성

• 구현할 기능을 issue로 발행하고, 이를 구현할 branch와 연결

3. 프로젝트에서 중요한 것 - 일정 지키기

• 일정을 지키는 것이 구현 완성도 보다 중요할 수 있음
• 현업이라면 더욱 중요
• 프로젝트 설계부터 책임과 권한이 있다면 기간을 우선으로 task를 계획하자

4. pathvariable vs request parameter

• RESTful한 api 설계시 entity의 id를 url로 전달해야하는 상황
• 고민할 주제는 아닐 수 있다(특별한 답도 없는것 같다)
• 그냥 팀의 방식을 정해서 하는 것이 이로울 수 있음

5. DB : recursive relationship

• ex) 숙소 타입이 상위 타입, 상위 타입에 속하는 하위 타입이 있음
• 두 타입 정보를 각각의 table로 두는 것 보다
• 상, 하위 관계가 있다면 recursive relationship을 사용하는 것도 괜찮은 선택인듯
• 교과서의 예제로만 보던 것을 실제로 겪어봄