7/15

• @EnableJpaAuditing : config 분리 vs Application에 어노테이션 설정

  [Junit] DataJpaTest 사용할 때 EnableJpaAuditing 주의

• @NotNull vs @Column(nullable = false)

• Soft Delete 적용

• 타임슬롯 하나하나에 마킹 → start/end만 저장 → NoSQL/JSON으로 저장 형태 변경

  • available_date 에도 똑같이 적용할 수 있음

• @OneToOne fetchType : LAZY vs EAGER

• 디비 연관관계 다 매핑 해야하나… 지하철 노선도마냥 너무 복잡하다..

  • 특히 Meeting에 있는 시작시간아이디, 종료시간아이디 등등
    • 아님 TimeSlot 없애고 그냥 시간값만 넣기

• TimeSlot 테이블이 필요 없을 수도 있을 것 같고, 값을 그대로 저장하는 건 어떨까

  • 현재 TimeSlot 테이블을 검증용으로 사용하고 있고, 시간에 관련된 모든 컬럼들에 대해 time_slot_id를 사용하고 있음
  • 이 때문에 너무 불필요한 연관관계가 생기고, 장점이 흐려진다.
  • 올바른 시간인지 검증하는 부분은 어플리케이션 단에서도 충분히 할 수 있을 것 같다.

7/15

• 현재 ERD에서는 meeting과 guest를 연결시켜주는 테이블이 schedule밖에 없음

  • meeting1의 다온과 meeting2의 다온을 구분하기 어려움

    

7/18

Schedule 수정하는 로직

• 사용자가 최초 시간을 등록할 때 시간과 사용자가 마지막으로 시간을 수정할 때(또는 등록할 때)시간을 어떻게 로그 정보에 담을까?

• 비트마스킹 활용 가능하지 않을까? → 교집합 구할 때 매우 편할듯?