실습도중 실수로 onetoone에다가 many로 넣어버렸는데 데이터가 들어가집니다.

이해했습니다. 결국 물리적으로 데이터베잇에 직접 하이버네이터가 unique 제약조건을 걸어둘거라고 착각을 한 제 잘못입니다.

다시 생각을 해봐도 OneToOne 매핑 해줬다고 제약조건 까지 걸어줘 버리는건, 개발자가 예상치 못한 제약조건이 들어가버린 다는 뜻이되니,  다음과 같이 어느정도 허용은 해주는게 맞는 것 같습니다. 

유니크 말고도 여러가지 방법이 있다는 점이 재밌어지네요. 제 생각에도 유니크만이 최선의 방법이라고 생각하지는 않습니다. 

결국 unique때문에 데이터베이스 에서 예외처리가 나온다면, 개발자가 의도한 바가 맞을 수 있겠지만,  로그에 error stack trace가 쭉쭉 올라가고 나중에 서버를 올렸는데, unique 제약조건 때문에 다른에러랑 구분하기 힘들정도로 가독성이 떨어지는 경우도 무시할 수는 없겠고요. 

그래서 데이터를 디비에 직접 저장하기전에, 쿼리를 먼저 날려서 지접 자바코드로 데이터의 중복이 있는지 없는지 알려주는 방법도 있을 수 있다고 생각합니다. 하지만 데이터를 넣기전에 쿼리를 날려서 직접 유니크 제약조건을 체크해준다는 것도, 성능을 고려했을 때에는, 좋은 방법은 아니라고 생각합니다.  

어려우면서 재밌어지네요. ^^ 혹시 다른분들도 저랑 같은 생각을 할 수 도 있으니 제가 한번 정리해 보았습니다.  답변 달아주셔서 감사합니다. 

ㅎㅎ 석민님 잘 정리하셨네요^^

결국 unique 제약조건을 걸어주는게 맞습니다.

제가 이야기한 다른 방법이라는 것은 관계형 데이터베이스에서 1:1 관계를 맺는 방법이 몇가지 있다는 뜻입니다.

주 테이블의 PK를 그대로 받아서 1:1 관계를 만드는 방법 등등이요.

애플리케이션에서는 사실 어떻게 해도 동시성 문제를 해결하기가 어렵기 때문에 명확한 1:1 관계는 데이터베이스의 unique 제약조건을 활용해야 합니다.

감사합니다.

안녕하세요. 석민님 좋은 질문입니다.

ORM에서 말하는 1:1, 1:N 관계라는 것은 사실 관계형 데이터베이스 기준의 관계를 말합니다.

그렇다면 관계형 데이터베이스에서 1:1 관계를 어떻게 만들면 될까요?

관계형 데이터베이스에서 1:1 관계를 만들려면 유니크 제약조건을 적절하게 걸어주어야 합니다. (참고로 1:1 관계를 만드는 방법은 여러가지가 있습니다.)

여기서는 SON의 FK 부분에 유니크 제약조건을 걸어주시면 1:1 관계를 만족할 수 있습니다. 그러면 데이터베이스에 저장하는 시점에 예외가 발생하겠지요.

객체 입장에서는 사실 객체의 참조에 값을 넣으면 되기 때문에 이 관계가 1:1인지 1:N인지 알 수 있는 방법이 없습니다.

잘 생각해보면 다대일 단방향 연관관계도 객체만 가지고 알 수는 없습니다. 다음 코드를 보시면 이해가 되실꺼에요.

@ManyToOne

Team team;

@OneToOne

Team team;

결국 이 N:M이라는 것은 관계형 데이터베이스를 기준으로 객체를 맞춘 것이라 이해하시면 됩니다.

이게 객체 그래프 방식과 관계형 데이터베이스 간의 차이로 이해하시면 됩니다.

감사합니다.

거의 비슷한 부분에서 의문이 들었는데 정말 상세한 질문과 답변 정리글이네요! ㅎㅎ 많은 도움이 되었습니다!