바로 바로 객체지향과 RDB테이블 패러다임 차이임
객체는 같은 놈은 같은 주소로 포인터 지정만 해주면 되는데
RDB 테이블은 그게 안됨 테이블엔 포인터라는게 없으니
무의미하게 반복해서 중복 데이터가 생겨버리는 것
핵심은 객체 포인터였네
오히려 N+1문제가 터져게 냅두는게 객체지향스러움이구나
자연스럽게 중복 데이터는 메모리에서 캐싱되도록
fetch join이 성능을 올릴 순 있지만
join으로 반복데이터 문제를 생각해야한다
그럼 또 궁금한게 RDB에서는 왜 포인터를 안쓸까?
유저1명이 N번 주문을 조인하면
유저 정보가 N번 생기는걸 포인터로 같은 레코드를 보게 처리하면 안될까?
이에 대한 답은 더 공부한 후에
To be continue...
- dc official App
'모든 데이터를 nosql로 옮겨 n+1 문제를 해결'
정규화 포기하고 컬럼에 다 박아버리기
객체 지향 데이터베이스 ㄱㄱ
뭐야 객체지향데이터베이스가 이미 있구나 - dc App
조영호님 강의들음?
아니 딱히 강의에서 배운건 아니고 N+1 가지고 오래 생각하다보니 깨달음 - dc App
여유 있으면 나중에 jpa의 사실과 오해 라는 오프라인 강의 들어보셈 나도 들었는디 시야가 많이 넓어짐
나는 너가 말한거랑 반대로 생각함 테이블은 다 양방향인데 객체간의 관계는 연관을 맺지 않으면 참조가 불가능해서, 연관관계의 주인이 아닌 곳에서 다중조회를 하려고 하면 결국 내가 누구와 연관이 있는가? 하는 객체를 퍼오는 +1 select가 필요하다고 생각했거든
늦은 댓글이긴한데 쿼리에 mapper만 만지다 jpa쓰면서 느낀 이질감? 딜레마?가 이런 부분이다라고 생각했음