slice 질문 드립니다,,

Question

안녕하세요 선생님 저번에 남긴 질문에 대한 해답을 못 구해 질문을 남깁니다.   제가 원하는 설계는 예를 들어, 유저 model에서 유저가 남긴 댓글들을 저장하는 array field를 만들고 이를 nesting으로 최신순 10개를 저장하는 것입니다. 이는 pagenation의 개수를 10개로 하려고 하기 때문입니다. 그러면 유저의 마이페이지에서 유저가 남긴 댓글들을 보여주는 페이지에 들어간다면, 백엔드에서는  이에 관한 api의 로직을 유저 model을 한 번 호출하여 필요한 data를 프론트에 주도록 구현하였습니다. 이러한 상황에서, 유저가 총 20개의 댓글을 남겼고 유저가 "유저가 남긴 댓글들을 저장하는 array field"에 저장된 댓글을 삭제 할 경우, 위의 api대로 작동한다면 최신순 10개의 댓글을 줄 수 있음에도 불구하고 9개밖에 주지 못하는 상황이 발생합니다. 1) "유저가 남긴 댓글들을 저장하는 array field"의 개수를 삭제 연산이 진행되더라도 10개를 보장해주는 방법에 대해 감이 오질 않습니다.. 2) 삭제연산을 할 경우 개수를 보장해주길 원한다면 로직이 너무 까다로워지는데 nesting으로 설계하는 것이 과연 옳은가? 라는 생각이 듭니다. 감사합니다..!

Dev · Answer

그렇군요 답변 감사합니다 선생님. 선생님 조언에 따라 잘 마무리해보겠습니다. 감사합니다 :)

sihoon · Answer

백엔드에서 불러와서 처리해야한다는게 다음과 같은 방법을 말한거였습니다!  await Comments . deleteOne ({ _id : commentId }); if ( user . comments . find ( c => c . id === commentId )){ user . comments . filter ( c => c . id !== commentId ); if ( user . comments . length > 0 ){ // $gt, $lt 여부는 기본 정렬 설정에 따라 달라집니다 const newComment = await Comment . findOne ({ userId , _id : { $gt : user . comments [ user . comments . length - 1 ]. id }}); if ( newComment ) user . comments . push ( newComment ); } await user . save () } 이렇게 하는게 아무래도 데이터를 정규화시켜서 populate로 불러오는 방법보다는 어쩔 수 없이 복잡합니다. 트래픽이 많지 않은 초기 서비스이고 개발시간이 촉박하시다면 populate로 시작하는것도 좋아요. 느려질 기미가 보이기 시작할 때 디비 설계를 위와 같이 변경하면 되니깐요. 물론 여유가 되시고 연습삼아서 하시는거면 이렇게 미리 해보시는 것도 좋고요 ㅎㅎ 중요한 포인트는 이렇게 설계도 가능하다에요. 단순 작동하는 디비와 백엔드를 만드는건 쉬워요(주니어 레벨). 어려운건(시니어 레벨) 많은 부하가 발생했을 때 혹은 서비스가 복잡해졌을 때도 잘 작동하게 할 수 있느냐에요.