Page History
...
Warning | |||||
---|---|---|---|---|---|
MS를 사용한 개발 진영은, SQL은 SP를통한 통제 방식이 개발이 권장이 아니라 정책적 변경불가한 요소인곳도 많이 봐왔으며 MS권장방식이라고 믿고 계신 DBA분들도 많이 봐왔으며, 아주 오랜전 결정된 정책( 그때 정책을 만든사람은 아무도 없음) 에 대한 이해및 히스토리가 대부분 없는 경우도 많으며 이것을 다시 셋팅하는것은 거의 쿠테타에 가까운것이였습니다. 그리고 SP를 통핸 개발방식은 장점이 훨씬많다란 굳은 믿음 그것을 타파해보겠습니다. 사실 MS는 JAVA오픈진영보다 훨씬더 빠르게 ORM을 통한 개발 요소를 프레임워크로 표준화하고 통합하였습니다. -Entity FrameWork MSSQL을 사용하면, 휼륭한 UI툴로 스토어프로시져를 포함하여 각종 스키마를 잘 관리할수 있는 방법을 꾸준히 제공해준것이 맞으며 실제로 UI를 통한 DBMS관리는 MSSQL을 따라올수 없다라고 보며..., 그 툴은 심지어 공짜입니다. UI로 잘관리할수 있다란것과, 개발정책에서 SP가 용이하다란것은 분리되어야 하는 이슈이며 그래서 어플리케이션 개발자가 ORM적용을 주도하려면 DB개발지식을 가지고 토론해야하기때문에 불편해지는 상황이 생길수 있습니다. 다음은 ORM 사용시 오해받는 몇가지 주제입니다.
외래키로 널허용이 금지된 1:1관계를 파악하고, JPA는 왜 자동으로 Inner Join을 걸게되는가?JPA를 설계한 쿼리가 일반 쿼리개발자보다 일반적으로 똑똑하다란 것입니다.대부분 쿼리로 개발한 개발자는 널허용여부에따라 왜 InnerJoin을 걸어야하는가에 대한 답을 빠르게 하지 못하지만JPA는 놀랍게 그러한 표준적인 쿼리성능 빌드에대해 고민을 하였으며 외래키에 Null허용을 할경우 놀랍게도 InnerJoin을 사용하지 않았습니다.물론 실행계획을 반영하여 극단적인 쿼리튜닝이 필요해 DBMS가 제공하는 네이티브 쿼리가 필요한 경우 ORM은 도움되지 않습니다.성능의 문제를 쿼리가 오브젝트를 관리하는 메시지중심으로 풀어갈수 있는 방법을 JPA가 제공해주지만 RDB와 어플리케이션이 가진 객체를둘다 이해해야하는것으로 ERD와 UML의 불일치를 해결을하고 , 그것을 일치하여 성능문제를 해결하려는 시도는쿼리를 극단적으로 튜닝해야하는 주제처럼 둘다 어려운주제로..., JPA의JPA가 모든상황에 성능이 항상떨어진다라는것은 올바르지 않습니다.
DB용어를 사용하여 조급더 고급지게 접근해보겠습니다.
JPA-ORM은 기본적으로 DDL/DML/DCL을 모두 할수 있는 구조입니다. 이것은 ORM이해가 아닌 기존 RDB가가진 언어입니다. 접근 정책정의에 있어서 중요요소 3가지를 빠트리고 이야기가 진행되는경우가 많지만... 정책결정은 위 3가지를 포함해서 이야기되어야하는 항목으로 생각됩니다. 그리고 각각 형상관리와 배포계획은 어떻게 세울것인가란 복잡한 이야기로 연결될수 있으나, 우선 배포는 배제하겠습니다. SP를 이용한 장점:
ORM을 이용한 장점:
SP를 통한 DB개발에서 이야기하는 장점이 오늘날에는 단점이 된 케이스가 일부있고 서로 상반된 이야기를 하기때문에 풀어나가기가 어려운 주제임은 분명합니다. 정답은 어렵고 권한이 없는이상 이것을 힘들게 주도하여 바꾸는것을 권장하지 않습니다. 언젠가 쓰일수 있으며, 왜 ORM은 우리회사에 적용이 어려운가란 주제는 RDB를 공부하는데 아주 좋은 주제가 될듯 합니다. |
...