문제점
리뷰 기능을 만들다가 '데이터를 어떻게 저장해야 하는가?'에 대한 생각이 들었다. 가장 고민이 된 부분이 사용자의 사진과 닉네임을 넣어야 하는데 리뷰 데이터에 직접적으로 넣는게 좋은 것인지 아니면 uid만 저장을 한 뒤에 리뷰를 호출해서 출력할 때 저장된 uid를 가지고 사용자의 데이터를 한번 더 호출하는 것이 좋은지에 대한 부분이 헷갈렸다.
각가의 장단점
1. 사용자의 데이터를 직접적으로 저장
- 장점 👍🏻
-
단순화된 쿼리: 필요한 모든 정보가 각 리뷰 내에 저장되므로 리뷰 검색 및 표시가 더 간단해졌습니다. 리뷰를 표시할 때 사용자 데이터를 가져오기 위해 추가 쿼리가 필요하지 않습니다.
-
서버 부하 감소: 사용자 정보는 리뷰와 함께 저장되므로 리뷰 표시 중에 사용자 세부 정보를 가져오기 위해 추가 요청을 할 필요가 없습니다.
- 단점 👎🏻
-
데이터 중복성: 각 리뷰와 함께 사용자 정보를 저장하면 동일한 사용자가 여러 리뷰를 작성할 경우 중복이 발생할 수 있습니다. 사용자가 정보를 업데이트하면 여러 기록을 업데이트해야 할 수도 있습니다.
-
데이터 일관성 문제: 사용자 정보가 변경되면 일관성을 유지하기 위해 해당 사용자와 관련된 모든 리뷰를 업데이트해야 합니다.
2. uid를 저장 후 별도로 사용자의 정보를 호출.
- 장점 👍🏻
-
데이터 정규화: 이 접근 방식은 사용자 정보를 별도의 위치에 저장하고 필요한 경우 참조하여 중복을 방지하는 데이터 정규화 원칙을 준수합니다. 이는 보다 체계적이고 효율적인 데이터베이스 구조로 이어질 수 있습니다.
-
일관성: 사용자가 프로필 사진이나 닉네임을 업데이트하면 사용자 정보가 중앙에 저장되므로 변경 사항이 모든 리뷰에 자동으로 반영됩니다.
-
데이터 저장 용량 감소: 각 리뷰마다 필수 정보(uid, 콘텐츠, 날짜)만 저장하므로 중복되는 데이터의 양이 줄어듭니다.
- 단점 👎🏻
- 추가 쿼리: 사용자별 정보를 검색하려면 리뷰를 표시할 때 사용자 데이터를 가져오는 추가 쿼리가 필요합니다. 이로 인해 특히 많은 수의 리뷰를 처리하는 경우 코드가 더 복잡해지고 성능이 느려질 수 있습니다.
결론
둘 다 각각의 장점과 단점이 존재하고 내가 만들고자 하는 서비스의 주요 목적과 사용자의 사용량에 따라 결정을 해야 한다고 생각을 했다.
그 결과 내가 내린 결론은 데이터 자체에 사용자의 이미지와 닉네임을 넣자이다. 왜냐하면 사용자가 자신의 프로필을 수정했을 때 해당 사용자의 댓글과 리뷰 등의 데이터의 정보를 업데이트 하는 것은 UX적으로 크게 문제가 없다. 하지만 uid를 저장하는 방식은 무조건적으로 추가적인 데이터 통신이 필요하고 결국 사용자 입장에서는 로딩 시간이 비교적으로 길어지는 불편함을 느낄 수 있기 때문이다.
