웹 프레임워크 내에서 DB를 제어하는 핵심 라이브러리가 무슨 특징을가지고 있는지? 위 도표를 이해하고 구분하는 개발자및 DBA를 단 한명도 만나보지 못했습니다개발자를 만나기는 어려웠습니다.
그리고 닷넷에서 ASP.net개발자가 기본으로 MS가 선물로주는 DB라이브러리가 무엇인지? 알고있고 구분해서 사용하는 개발자분도 만나보지 못했습니다만나기 어려웠습니다.
닷넷을하던 자바를하던.., 자신이 사용하는 기술이 상대편에서는 어떠한 형태로 사용되어지는지 파악하는것은 아주 중요한 요소라고 생각합니다.
Mybatis가 ORM이다라고 하시는분도 있으며, JPA는 쿼리를 모르는 개발자가 쉽게개발하기위해 성능을 올릴수 없는 저급한 플랫폼이다라고 결론짓는 분도 보았습니다.
그리고 또한 심각한것은 MS를 사용하는 진영은 SP로만 개발해야된다란 믿음에서 벗어나지 못한다란것입니다.
자바 오픈진영에서 ORM은 여러기술이 경쟁을 펼치고 몇개로 표준이 되는반면 MS에서는 애시당초 ORM 기술을 하나로만 진행하고 표준화하였으며 , Spring에 JPA를 셋팅하는과정보다 훨씬 쉽습니다.
위 도표를 그린 이유는, ORM을 여러가지 이유로 적용할 준비가 안되었다라고 하면
Enterprise Library VS 이 이슈는 Enterprise Library → Mybatis 의 차이점을 심도있게 살펴봐야하는게 맞다고 봅니다.
또한 닷넷VS자바 - Entity framework VS JPA 를 이야기 해야하는 시대여야 한다고 봅니다.
DBA를 포함하여 웹개발자중에 위 도표를 이해하는 분이 주위에 없다고 하면
검토할수 있습니다.
주위에 두가지 위 도표를 이해하고 차이에대해 고민을 못하였다고하면 아직도 SP개발 VS 쿼리개발방식만 이야기할수 있는 수준이라고 하면있습니다.
아직 우린 ORM으로 가기위한 준비를 더 할 필요가 있겠습니다ORM으로 가기위한 준비가 하나도 안되었다라고 보면됩니다.
다시 MS개발진영으로 문제범위를 좁혀보겠습니다.
MS를 사용한 개발 진영은, SP를 통한 개발방식이 권장이 아니라 정책적 타협 불가한 요소인곳도 봐왔으며있을수 있으며
심지어 이것이 MS권장방식이라고 믿고 계신분들도 있습니다. 아주 오랜전 결정된 정책( 그때 정책을 만든선배들은 이미없음) 에 대한 이해및 히스토리가
대부분 없는 경우도 많으며, 현재 고착화된 DB개발 정책을 약간이라도 변경하는것은 아주 큰모험에 가깝다라고 생각합니다가까울수 있습니다.
우선 SP를 통한 개발방식의 절대적인 장점 그러한 굳은 믿음 ,그것을 타파하는것에 시작을 해보겠습니다.
사실 MS는 JAVA오픈진영보다 훨씬더 빠르게 ORM을 통한 개발 요소를 프레임워크로 표준화하고 통합하였습니다. -Entity FrameWorkMSSQL을 사용하면, 휼륭한 UI툴로 스토어프로시져를 포함하여 각종 스키마를 잘 관리할수 있는 방법을 꾸준히 제공해준것이 맞으며
실제로 UI를 통한 DBMS관리는 MSSQL을 따라올수 없다라고 보며..., 그 툴은 심지어 공짜입니다.
UI로 잘관리할수 있다란것과, 개발정책에서 SP가 용이하다란것은 분리되어야 하는 이슈이며
그래서 어플리케이션 개발자가 ORM적용을 주도하려면 DB개발지식을 가지고 토론해야하기때문에 불편해지는 상황이 생길수 있습니다.
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의 불일치를 해결을하고 , 그것을 일치하여 성능문제를 해결하려는 시도는