[2] 디지털 잡지 iOS App 서비스

한 달에 한 번 N월 호를 업로드하면 점차 많은 글이 쌓여갈 것이다.

분류 탭에서 여러 글을 분류하여 사용자가 쉽게 글을 찾아볼 수 있게 하려 한다.

 

글을 두 가지 기준으로 분류한다.

• N월 호
• 지역
  • 특정 장소에 대한 글이 업로드될 예정이고 대게 서울특별시에 위치하고 있다.
  • 구를 기준으로 분류한다.
  • 가끔 서울특별시 밖의 위치하는 장소는 그외로 분류한다.

우선 관계형 데이터베이스를 사용한다는 가정하에 테이블을 설계한다면. 두 개의 테이블이 필요할 것 같다.

• N월 호 (monthly_magazine)
  • id (PK): YYYY-MM
  • 글 id
• 글 (cafe | article)
  • id (PK): unsigned int
  • 지역구
  • 등...
• 이미지 (cafe_image)
  • id (PK): unsinged int
  • 글 id
  • 이미지 저장 경로: 파일 스토리지 버킷 주소

마지막으로 테이블 간 FK 설정은 하지 않았다.

 

최근에 '제미니의 개발실무' 채널을 알게 돼서 많은 내용들을 접했다.

많은 내용 중에 FK 설정에 대한 영상이 있었는데 꽤 많은 공감을 했다. 그래서 이번 프로젝트에서는 FK 설정을 선택 사항으로 반영해보려 한다.

 

[FK 설정 관련 영상 내용 발췌]

엔티티의 생명 주기, 연관성이 동일하다면 FK 설정을 해야 한다는 것이다. 그러나 이 또한 선택 사항인 것 같다.

 

정규화된 테이블이라고 연관 관계를 항상 설정하면,

개발하거나 운영 시에 데이터를 수정 및 변경할 때 불편함을 겪는 경우가 꽤나 있다.

영상에서는 Order(1)와 OrderItem(N)을 예시로 설명했다.

 

예를 들어 OrderItem의 상태를 변경시킬 때, 많은 사람들이 order.orderItems에 접근하여 orderItem의 상태를 변경한다는 것이다. 다시 말해, orderItemRepository를 사용하지 않으며, OrderItem의 상태 변경 함수 또한 Order 엔티티에 둔다는 것이다. 

운영 시에 데이터가 꼬여 데이터를 삭제하고 생성 및 수정해야 할 때, 연관 관계가 걸려 있다면 묶여 있는 순서대로 데이터를 생성하거나 전체를 순서대로 지워야 한다. FK 설정을 통해 데이터의 무결성과 정합성을 잘 지킬 수 있지만, 이것이 없어도 잘 지킬 수 있다고 생각한다.

 

Order 조회 시, OrderItem을 FetchJoin으로 가져오는데 이 때 많은 순환 참조가 발생한다고 한다.

그래서 DB와 엔티티에 연관 관계를 설정하지 않고 어떻게 이를 하냐면,

도메인 객체를 두어 이를 풀 수 있다.

OrderEntity와 OrderItemEntity는 ORM에 의존하는 클래스이다.

순수 데이터 클래스인 Order를 두는 것이다.

class Order:
    id: int
    ...
    order_items: list[OrderItem]
 
 
 class OrderItem:
     pass

 

영상을 보고 해당 방식이 공감되고 이해된다면, 연관 관계가 없더라도 올바르게 데이터를 생성하고 조회하는 데에 문제될 것은 없다고 생각한다.

 

ORM은 이전의 문자열을 통해 SQL을 Mapping 했을 때, 생기는 실수를 줄이고 코드로 SQL을 작성하므로써 이를 방지함에 장점이 있다고 생각한다.