팀바팀이긴 한데, 이유를 찾아보면 실무에서는 1.외래키가 있으면 제약조건 때문에 추가 변경, 확장할때 불편하다 2.cascade 같은 옵션을 사용하는 경우, 예상하지 못한 데이터 삭제, 추적의 어려움 3.제약조건 검사에서 오는 삽입, 삭제 작업 등의 오버헤드 발생 이런 이유들이 있던데, 맞음? 외래키를 사용안하면, 참조 관계일 경우에는 그 관계를 개발자가 기억해놔야 함?
너가 이해한 이유가 맞다 ㅇㅇ - dc App
이것만큼은 이유를 알 필요 없이 그냥 안하면 됨 외래키 관계는 기억하기 쉽게 컬럼명에 해당 테이블명을 프리픽스로 붙이는게 관례
물론 그 이유가 맞긴 한데, 더이상 의문을 가지지 말라고
그럼 엔티티 설계할때, jpa에서 manyto~ 사용할 때 foreignKey 속성의 NO_CONSTRAINT 을 추가함? 아니면 그냥 참조관계 설정안하고, 부모 테이블 pk(user_id, post_id 같은)를 그냥 엔티티 컬럼에 적음?
보통은 jpa ddl을 사용하지 않음 객체참조 간접참조 선택은 편한대로 하는게 맞고
주로 위에 애가 말한대로 하는게 맞음 너무 jpa틱하게 개발하면 복잡도가 증가하고 동작을 이해기 어렵게 됨 장점만 빨아먹어야지 기술에 휘둘리면 안돼
아 고마워<br>jpa 공부할때는 엔티티 설계할때 참조관계를 설정하도록 배웠는데, 실무에서는 참조관계일때도 외래키 제약을 안건다고 하니까 약간 괴리감이 와서 질문했어 답변 내용은, 그냥 테이블 설계할때 jpa로 자동생성 하지말고, 직접 sql의 ddl 쿼리로 테이블 생성하고, jpa 코드상에서는 ddl 생성 옵션을 안주는 식으로 해결하라는 거 맞아?
그 말도 맞고 걍 jpa에 참조관계 설정을 아예 안해버리는 경우도 많음 객체그래프 탐색 기능 같이 orm스러운거는 다 제끼고 그냥 편의기능만 쓰는거
jpa 엔티티를 도메인 삼아서 로직을 채워넣다보면 너무 뚱뚱해지거든 이거 싫어하는 사람들 많음
ㄱㅅㄱㅅ생각해봤는데, 굳이 객체 그래프 탐색으로 a테이블.getB테이블.getC컬럼으로 안하고, join 쿼리로 해결할 수 있을 듯 그냥 자바코드로 db를 다룰수 있다 는 장점만으로 충분한거네