ORM에서는 쿼리 최적화가 불가 ==> 표준화되지 않는 각종 DB의 네이티브 쿼리의 방언을 이해하고 있습니다. 심지어 SQL2000버젼부터 2018년 버젼까지 다른점도
ORM은 쿼리 개발을 모르는 초짜가 사용하는 기술이다. ==> QueryDSL은 SQL을 이해못하면 람다식으로 SQL식을 풀어낼수 없으며, 쿼리작성보다 엔티티를 먼저 맞추는데 시간을 들입니다. 그리고 쿼리식과 람다식은 닯아있습니다. ORM에서 오히려 순차적 중복 쿼리 호출을 방지하는 장치가 있습니다. SP내부에서 SQL문이 오히려 여러가지 순차 SQL문을 만들가능성이 있습니다.
ORM은 ERD를 그려낼지 모르는 개발자가 사용하는 기술이다 - ==> 기존개발방식이 ERD설계된 관계를모르고, 조인남발 쿼리로 잘못된 집합체를통한 뷰어개발이 가능합니다. 그리고 대부분 ERD설계가 존재하지 않습니다 , ORM에서 ERD관계를 맞추지못하면 빌드 조차 안되는 경우가많습니다. 그렇기때문에 ERD 설계도가 없다고치면 그관계 파악이 우선입니다.
외래키로 널허용이 금지된 1:1관계를 파악하고, JPA는 왜 자동으로 Inner Join을 걸게되는가?
JPA를 설계한 쿼리가 일반 쿼리개발자보다 일반적으로 똑똑하다란 것입니다.
대부분 쿼리로 개발한 개발자는 널허용여부에따라 왜 InnerJoin을 걸어야하는가에 대한 답을 빠르게 하지 못하지만
JPA는 놀랍게 그러한 표준적인 쿼리성능 빌드에대해 고민을 하였으며 외래키에 Null허용을 할경우 놀랍게도 InnerJoin을 사용하지 않았습니다.
물론 실행계획을 반영하여 극단적인 쿼리튜닝이 필요해 DBMS가 제공하는 네이티브 쿼리가 필요한 경우 ORM은 도움되지 않습니다.
성능의 문제를 쿼리가 오브젝트를 관리하는 메시지중심으로 풀어갈수 있는 방법을 JPA가 제공해주지만 RDB와 어플리케이션이 가진 객체를
둘다 이해해야하는것으로 ERD와 UML의 불일치를 해결을하고 , 그것을 일치하여 성능문제를 해결하려는 시도는