<aside> 📌 **아니다.
대규모의 서비스의 경우에는 오히려 장애를 일으킬 원인으로 이어질 수 있다.**
</aside>
CASCADE를 하기 위해서는 주 객체에서 대상 객체로 관계가 맺어지게된다.
이 상황에서 필요없는 양방향의 관계가 이어질 수 있으며,
주인이 모호해지는 상황이 발생할 수도 있다.
대상 객체에 여러 주 객체들의 CASCADE 매핑이 이어진경우
주인이 모호해지는 상황과 더불어 어디서 어떻게 장애가 발생할지 모른다.
또한 굳이 양방향을 복잡하게 가져갈 필요가 없다고 생각된다.
n+1 문제가 발생한다.
회원과 좋아요가 CASCADE 관계를 가지고, 회원이 지워지면 좋아요는 자동으로 삭제된다고하자.
그럼 이때 좋아요를 몇만개 누른 회원이 탈퇴하는 경우, delete쿼리는 어떻게 나가지나?
모든 좋아요에 각각에 대해 하나의 쿼리씩 발생하게 되는 문제가 발생한다.
이것은 곧 DB에 부하의 원인이 될 수 있다.
<aside> 📌 따라서 나는 이런 경우에만 CASCADE를 사용하는 것을 권장한다.
1. 주 객체와 대상 객체 간에 관계의 개수가 제한적인 경우 (위에서 든 예시와 같이 관계의 개수에 제한이 없는 경우에는 n+1 문제에 직면한다.) (따라서, 게시글 - 파일 , 파일 개수 제한 3 이런식으로 제한된 관계의 경우에는 필요하다고 생각된다.)
2. 트래픽 처리가 많지않고, 빠른 완성 (개발)이 필요한 소규모의 프로젝트의 경우 ( 물론 되도록이면 CASCADE를 남용하지 않는 것이 좋으나, 급하게 개발을 하는 경우에는 코드의 수도 절약이 가능하고 이해를 직관적으로 할 수 있기때문이다. )
</aside>