1/18 최종 프로젝트 5

내일배움캠프 오늘 학습 내용

 

• 최종 프로젝트 : order CRUD 개발, review CRUD 개발

 

 

ERD에 대한 고찰

 

order 테이블에서 update를 할 때 status에 따라 내용이 달라질 수 있는 점을 생각하여 해당 api를 각각 나누어 개발하였다. admin이 환불을 진행하면 역시 user의 point를 환불시키도록 진행하였다. 하지만 여기의 데이터 관리를 어떻게 해야할지에 대한 고찰은 계속 생각하는 중이다. order할 때 당시의 user의 poin와 사용한 point 를 저장하는 로그 table이 또 필요하지 않을까 생각하여 이 부분에 대해서는 다음에 추가 개발을 진행하 때 만들 수 있다면 만들 예정이다. 또 repository를 직접 가져오는 것보단 다른 모듈의 service를 가져오는 방식이 더 효율적이라고 피드백을 들어 나중에 새로운 table의 추가와 함께 전체적으로 order 모듈은 수정을 진행할 예정이다.

 

또, review 테이블은 현재 user_id를 저장하고 있지 않아 외래키인 order_id를 통한 join으로만 얻을 수 있는데, 데이터 중복을 포함하여 효율성을 선택하는 것이 좋은지 정규화와 반정규화를 어떻게 진행하는 것이 좋을지 고민 중이다. 현재는 user_id가 없으니 모든 메서드에서 order service를 불러와 order 값을 불러와서 확인하여 보여주는 방식으로 구현하였다.(여기서부터는 피드백 받은 대로 repository가 아닌 모듈을 import하여 사용하는 중이다.)

 

처음 개발을 하기 전부터 이 부분의 erd가 부정확하다고 느꼈고, 매 순간 바뀌고 있었기에 그 부분을 확실히 하고 싶어 이 쪽 부분의 개발을 자원하였는데 예상했던 대로 api를 구현하며 database의 수정과 고민이 가장 많이 생기는 부분이 되었다. 예를 들어 앞서 말한 user가 point를 어떻게 사용하고 환불받았는지 저장하는 log 테이블은 다음 구현에 적용할 것이고, 만약 할인을 통해 product의 가격이 바뀔 때 나중에 불러와서 문제가 될 수 있으니 order 테이블은 data가 늘어나더라도 당시의 product의 가격, 이름, user의 정보 등을 저장하는 것 역시 좋다고 들었다. 혹은 주문서와 결제 내역, 배송지 등을 저장하는 테이블을 나누는 것이 좋을 것 같았다. 이런 식으로 어떻게 data을 나누고 효율적으로 처리하고 실제로 구현할 수 있는지에 대한 고민을 계속 진행하여 실제 대규모 쇼핑몰에서 사용하는 api처럼 최대한 구현하는 것을 목표로 하고 있다.