개발자
Post 테이블 (Long pno, String cotent) UserInfo 테이블 (String uid, String nickname) PostLike 테이블 (Long pno, String uid) Post에 대한 좋아요 정보를 PostLike테이블에서 관리하고 있습니다. 여기서 PostLike 엔티티를 정의할 때 1) UserInfo userInfo, Post post를 @ManyToOne으로 관리할지, 2) 아니면 그낭 Long pno, String uid로 관리할지 고민입니다. 1번 방법) 장점 : Post, UserInfo를 delete 할때 알아서 관련된 좋아요 정보를 찾아서 삭제해준다는 면에서 무결성 관리가 편함. 단점 : JPA는 where pno=(삭제하는 게시글 id)처럼 쿼리 한 번으로 삭제하지 못 한다. 먼저 PostLike 테이블에 pno가 삭제 게시글 id와 같은 것들이 무엇이 있는지 확인하고, 해당 id에 해당하는 row를 deleteById로 하나하나 삭제하기 때문에 쿼리가 N+1 필요해서 성능 이슈가 생긴다. 2번 방법 ) 장점 : 성능 문제가 해결된다. 쿼리 한 번으로 게시글 혹은 유저를 삭제했을 때 관련 좋아요 정보를 삭제할 수 있다. 단점 : 무결성 관리를 직접 해줘야 해서 프로그래머가 신경써서 관리해야 한다. ◼️ 질문 1 1번 방법과 2번 방법 중에서 2번 방법을 선택하려고 합니다. Trade off를 제대로 한 게 맞을까요? Post와 Comment에서는 @ManyToOne을 사용하고, Follow나 PostLike에서는 @ManyToOne을 사용하지 않는 것이 제멋대로인 것 같아서 고민입니다. ◼️ 질문 2 유저를 삭제할 때 해당 유저가 좋아요를 누른 기록을 유지하는 것이 좋을까요, 삭제하는 것이 좋을까요? 요구사항에 따라 달라진다는 것은 알지만 그래도 일반적으로 사용되는 방법이 궁금합니다.
답변 0
첫 답변을 기다리고 있어요.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 07월 04일
두 가지 방법 모두 유효한 접근 방식이며, 무엇을 중요하게 생각하느냐에 따라 선택해야 합니다. 1번 방법은 객체 지향적인 설계를 위주로 하고 있으며, 데이터의 무결성을 자동으로 보장하는 데 강점이 있습니다. 그러나 말씀하신대로 성능 이슈가 발생할 수 있습니다. 2번 방법은 성능 최적화에 초점을 맞추고 있습니다. JPA에서 제공하는 객체 관계 매핑 기능을 일부 포기하여 대신에 쿼리의 효율성을 추구하는 것입니다. 직접 무결성 관리를 해야 한다는 단점이 있지만, 이는 추가적인 코드 작성으로 커버할 수 있습니다. 따라서 trade-off가 잘 이루어진 결정이라 할 수 있으며, 어플리케이션의 규모나 성능 요구사항 등을 고려했을 때 2번 방법이 좋아 보입니다. Post와 Comment에서는 @ManyToOne을 사용하고, Follow나 PostLike에서는 @ManyToOne을 사용하지 않는 것이 제멋대로인 것처럼 보일 수도 있지만, 다양한 비즈니스 로직과 요구사항에 따른 설계 결정일 수 있습니다. 두 방법 모두 적절한 시나리오에서 사용될 수 있으며, 테이블의 성격과 어플리케이션의 요구사항에 따라 다르게 선택될 수 있다는 것을 기억해야 합니다. 물론 복잡성과 유지보수성도 고려해야 할 중요한 요소입니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!