2:13 "일단" 이라는 부분이 너무 우려가 되는 것 같습니다. (fk를 사용해서든, 논리적인 차원에서든) 기존에 합의된 무결성을 위반해 가면서까지 즉각적인 수정이 필요한 경우는 예외적인 장애 케이스로 보이는데 그걸 대비하기 위해 fk 를 걸지 않는다는건 너무 큰 위험부담이 아닐지?
'FK를 걸지 않는게 위험부담'이라고 생각하는 것 자체를 다시 생각해보시라고 말씀드리고 싶네요. '예외적인 장애 케이스'를 제외하고도 충분히 운영 상황에서 FK로 인해 불편함을 주는 일은 굉장히 많습니다. 전체 스펙 변경, 하위 호환, 마이그레이션, 장애가 아니더라도 데이터 보정, 특정 시점의 일괄 처리 등등.. (이거는 대규모 서비스에서 FK 걸고 운영을 꽤 길게 해보시면 느끼실텐데 추천하진 않지만 직접 걸고 데여보시길 바랍니다) 실제로 요즘 처럼 하드웨어가 좋은 시대에 미비하지만 FK는 성능 이슈도있고, 대용량 데이터 시점에 관리 차원에서 샤딩/파티셔닝을 걸어야할때 기대하는 동작도 잘 안 되고, 추가적으로 많은 불편함을 가져다 줍니다. 소규모 시스템이라 하더라도 FK에 의존하는 방식으로 유지하는 것은 DB 의존적인 형태로 가는 모습을 보여주기도 해서 더욱 비추합니다. 분명 예외적 케이스가 있겠지만 FK로 무결성을 보장해야하는 상황이라면 설계 변경이나 다른 아키텍처로 푸는게 좋아보입니다. 제 실무 경험 기준으로도 FK건 프로젝트들은 몇몇 SI 플젝 외에는 본 적이 없었던 것 같네요. 생각해 보시는데 도움이 되었길! :D
fk를 안 걸면 장점이 데이터 수정 삭제에 용이하다는 것을 인지하고 있는 상태입니다. 만약 게시글 엔티티에 댓글을 달아야 한다는 상황이 있을 때, JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다. FK없이 코드를 짠다고 하면 Service 코드에서 postRepository.findById(postId).orElseThrow() 를 생략할 수 있다는 장점도 생각했는데요. 이러한 경우 테스트 코드 작성할 때 게시글과 유저를 Repository로 만들지 않고 바로 댓글 서비스 코드 테스트가 작성하기 편하다는 장점도 생각했습니다. 잘못된 생각인 걸까요? 위에가 잘못된 생각이라면 무결성 검사는 필요 없지만, 엔티티 존재 여부는 항상 체크해줘야 하기 때문에 테스트 코드 작성할 때나, 실제 서비스 개발할 때는 FK 있고 없고 로직은 똑같나요?
>>만약 게시글 엔티티에 댓글을 달아야 한다는 상황이 있을 때, JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다. >>FK없이 코드를 짠다고 하면 >>Service 코드에서 postRepository.findById(postId).orElseThrow() 를 생략할 수 있다는 장점도 생각했는데요. >>이러한 경우 테스트 코드 작성할 때 게시글과 유저를 Repository로 만들지 않고 바로 댓글 서비스 코드 테스트가 작성하기 편하다는 장점도 생각했습니다. 이 부분은 게시글 과 댓글을 연관관계를 지은 상태의 예시를 들으신 것이라면 말씀하신 부분의 이점도 있다고 가정 할 수 있을 것 같습니다. -- > JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다. 다만 이 부분은 무조건이리고 보긴 어려울 것 같습니다, 게시글과 댓글의 연관관계를 끊어서 느슨하게 유지해두면 게시글이 무조건 필요하지 않으니까요! -- 마지막으로 테스트 코드에서 댓글에 대해서만 특정 케이스를 편하게 작성한다면 약간의 이점은 있을 수 있지만 통합적으로 테스트한다면 게시글이 필수 일 것이므로, FK 유무가 로직을 크게 다르게 한다고 보긴 어려울 것 같습니다.
영상 감사합니다. 가려웠던 곳을 긁어주는 느낌이라 영상 하나하나 다 챙겨보고 있습니다. 복 받으십쇼,,,,
봐주셔서 감사합니다!
이 질문 올리고 나서 마침 프로젝트 2개중 하나는 외래키가 빡빡하게 걸려있고, 하나는 외래키를 거의 안건 프로젝트를 진행중인데 많이 공감이 가네요
항상 너무 상세한 설명 감사합니다!
질문 감사드립니다! 도움이 되었다면 다행이네요!
출근길 최고의 선택!
오늘도 감사합니다 :D
봐주셔서 감사합니다!
2:13 "일단" 이라는 부분이 너무 우려가 되는 것 같습니다. (fk를 사용해서든, 논리적인 차원에서든) 기존에 합의된 무결성을 위반해 가면서까지 즉각적인 수정이 필요한 경우는 예외적인 장애 케이스로 보이는데 그걸 대비하기 위해 fk 를 걸지 않는다는건 너무 큰 위험부담이 아닐지?
'FK를 걸지 않는게 위험부담'이라고 생각하는 것 자체를 다시 생각해보시라고 말씀드리고 싶네요.
'예외적인 장애 케이스'를 제외하고도 충분히 운영 상황에서 FK로 인해 불편함을 주는 일은 굉장히 많습니다. 전체 스펙 변경, 하위 호환, 마이그레이션, 장애가 아니더라도 데이터 보정, 특정 시점의 일괄 처리 등등..
(이거는 대규모 서비스에서 FK 걸고 운영을 꽤 길게 해보시면 느끼실텐데 추천하진 않지만 직접 걸고 데여보시길 바랍니다)
실제로 요즘 처럼 하드웨어가 좋은 시대에 미비하지만 FK는 성능 이슈도있고, 대용량 데이터 시점에 관리 차원에서 샤딩/파티셔닝을 걸어야할때 기대하는 동작도 잘 안 되고, 추가적으로 많은 불편함을 가져다 줍니다.
소규모 시스템이라 하더라도 FK에 의존하는 방식으로 유지하는 것은 DB 의존적인 형태로 가는 모습을 보여주기도 해서 더욱 비추합니다.
분명 예외적 케이스가 있겠지만 FK로 무결성을 보장해야하는 상황이라면 설계 변경이나 다른 아키텍처로 푸는게 좋아보입니다.
제 실무 경험 기준으로도 FK건 프로젝트들은 몇몇 SI 플젝 외에는 본 적이 없었던 것 같네요.
생각해 보시는데 도움이 되었길! :D
@@geminikims 상세하고 세심한 답변 감사합니다!
이번 주제도 잘 봤습니다 : )
재민님 새해 복 많이 받으세요! 🙏
봐주셔서 감사합니다! 새해 복 많이 받으세요!
좋은 설명 감사합니다!
봐주셔서 감사합니다!
fk를 안 걸면 장점이 데이터 수정 삭제에 용이하다는 것을 인지하고 있는 상태입니다.
만약 게시글 엔티티에 댓글을 달아야 한다는 상황이 있을 때, JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다.
FK없이 코드를 짠다고 하면
Service 코드에서 postRepository.findById(postId).orElseThrow() 를 생략할 수 있다는 장점도 생각했는데요.
이러한 경우 테스트 코드 작성할 때 게시글과 유저를 Repository로 만들지 않고 바로 댓글 서비스 코드 테스트가 작성하기 편하다는 장점도 생각했습니다.
잘못된 생각인 걸까요?
위에가 잘못된 생각이라면 무결성 검사는 필요 없지만, 엔티티 존재 여부는 항상 체크해줘야 하기 때문에 테스트 코드 작성할 때나, 실제 서비스 개발할 때는 FK 있고 없고 로직은 똑같나요?
>>만약 게시글 엔티티에 댓글을 달아야 한다는 상황이 있을 때, JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다.
>>FK없이 코드를 짠다고 하면
>>Service 코드에서 postRepository.findById(postId).orElseThrow() 를 생략할 수 있다는 장점도 생각했는데요.
>>이러한 경우 테스트 코드 작성할 때 게시글과 유저를 Repository로 만들지 않고 바로 댓글 서비스 코드 테스트가 작성하기 편하다는 장점도 생각했습니다.
이 부분은 게시글 과 댓글을 연관관계를 지은 상태의 예시를 들으신 것이라면 말씀하신 부분의 이점도 있다고 가정 할 수 있을 것 같습니다.
--
> JPA에서는 게시글 엔티티가 무조건 필요한 걸로 알고있습니다.
다만 이 부분은 무조건이리고 보긴 어려울 것 같습니다, 게시글과 댓글의 연관관계를 끊어서 느슨하게 유지해두면 게시글이 무조건 필요하지 않으니까요!
--
마지막으로 테스트 코드에서 댓글에 대해서만 특정 케이스를 편하게 작성한다면 약간의 이점은 있을 수 있지만
통합적으로 테스트한다면 게시글이 필수 일 것이므로, FK 유무가 로직을 크게 다르게 한다고 보긴 어려울 것 같습니다.
@@geminikims 질문을 이상하게 했는데 다 이해하시고 답변 달아주신 거 정말 감사합니다!!!