📝 데이터 저장 및 업데이트

• DB에 영업 시간 저장의 문제

  • JSON 형태로 저장 예정이었지만 크롤링 과정에서 많은 시간이 소요
  • 정해진 형식이 있지 않아서 파싱에서 문제가 발생
  • 영업 여부를 보여주기 위한 컬럼이었는데, 다음차로 이동하는 동안에 영업 시간이 지날수도 있음

  ⇒ 데이터를 다루는 문제도 있고, 딱히 필요할 것 같지 않아서 해당 컬럼 삭제로 결론

• DB 데이터 저장 방식

  • API 호출
  • CSV 파일 활용

• 데이터 업데이트 방식에 대한 고민

  • API 호출을 하려면 매번 모든 데이터를 가져와서 비교해야함 ⇒ 생각보다 많은 시간이 걸리지 않음
  • CSV 파일을 통해 필터링을 걸고 업데이트를 진행 ⇒ 자동화를 할 수 없음

• 테이블 전략 수정

  • store를 상속 받는 테이블들의 컬럼이 모두 동일하기 때문에 상속 관계 사용은 맞지 않다고 판단
  • 상속 관계 사용 없이 단일 테이블 전략을 사용하도록 수정

📝 연관관계

• 양방향 or 단방향 매핑 선택 : 단일 객체를 조회할 때, 연관된 객체의 데이터가 정말 자주 필요하다면 양방향 매핑으로 설정
  • user - review는 단방향
    • 단일 user에 대한 review 탭이 따로 존재할 예정이므로 user를 조회할 때, 항상 review 정보를 받아올 필요가 없음.
  • store - review는 양방향
    • 단일 store 정보를 조회할 때는 항상 review 정보가 같이 보일 예정이므로 양방향 매핑으로 설정
    • 양방향 매핑이므로 review 수는 List의 사이즈로 개수를 지정하면 되기 때문에 DB 성능에 영향이 없을 것으로 판단
  • user - bookmark 단방향
    • review와 마찬가지로 단일 user에 대한 bookmark 탭이 따로 존재할 예정이므로 user를 조회할 때, 항상 bookmark 정보를 받아올 필요가 없음.
  • store - bookmark 단방향
    • 단일 store 정보를 조회할 때 bookmark 정보가 필요 없으므로 단방향 매핑으로 설정
    • bookmark 수 확인은 count 쿼리로 진행 예정
    • count 관련해서 성능 이슈가 있을 수 있는데, 이는 테스트 후에 개선 예정
      1. count를 필드로 갖고 북마크가 추가될 때마다 1씩 증가
      2. 양방향 매핑
• CascadeType 설정
  • user - review : PERSIST x, REMOVE x
    • user가 생성될 때, review가 같이 생성되는 게 아니므로 PERSIST를 설정하지 않음.
    • user가 삭제돼도 해당 review를 store에서 보여줄 예정이므로 REMOVE 를 설정하지 않음.
  • store - review : PERSIST x, REMOVE x
    • store가 생성될 때, review가 같이 생성되는 게 아니므로 PERSIST는 설정하지 않음.
    • store가 삭제돼도 해당 review를 user에서 확인할 수 있게 할 예정이므로 REMOVE 를 설정하지 않음.
  • user - bookmark : PERSIST x, REMOVE O
    • user가 생성될 때, bookmark가 같이 생성되는 게 아니므로 PERSIST는 설정하지 않음.
    • user가 삭제되면 해당 bookmark를 같이 삭제할 예정이므로 REMOVE 를 설정
  • store - bookmark : PERSIST x, REMOVE O
    • store가 생성될 때, bookmark가 같이 생성되는 게 아니므로 PERSIST는 설정하지 않음.
    • store가 삭제되면 해당 bookmark를 같이 삭제할 예정이므로 REMOVE 를 설정
• 연관된 데이터 조회 성능 비교
  • 연관된 데이터들을 조인으로 조회
  • 연관된 데이터들을 해당 테이블마다 직접 찾아서 조회

📝 기능

• 필터
  • 반경 적용
  • 카테고리로 분류
• 조건 적용
  • 거리
  • 평점
• 추천 방식
  1. 처음 의도대로 조합으로 추천
     • 조건을 각각 선택하게 하면 가중치를 고려해야 해서 쉽지 않음 ⇒ 조건을 각각의 차마다 적용하지 않고 전체로 통일해서 적용 (좀 더 단순화)
  2. 1차부터 시작해서 카테고리와 조건을 선택하면 우선순위가 높은 가게부터 목록을 보여준 후, 다음 차의 가게를 사용자가 직접 선택하도록 설정

📝 기타

• where와 on의 차이 확인 ⇒ inner join에선 차이 없음
  • where : join 후에 조건을 필터링
  • on : join 전에 조건을 필터링
• ServiceDto
  • 사용 의도 파악 ⇒ 당장은 필요하지 않을 거 같음.