Page History

MS를 사용한 개발 진영 진영은, SQL은 SP를통한 통제 방식이 개발이 권장이 아니라 정책적 변경불가한 요소인곳도 많이 봐왔으며

MS권장방식이라고 믿고 계신 DBA분들도 많이 봐왔으며, 아주 오랜전 결정된 정책( 그때 정책을 만든사람은 아무도 없음)

에 대한 이해및 히스토리가 대부분 없는 경우도 많으며 이것을 다시 셋팅하는것은 거의 쿠테타에 가까운것이였습니다.

그리고 SP를 통핸 개발방식은 장점이 훨씬많다란 굳은 믿음 그것을 타파해보겠습니다.

사실 MS는 JAVA오픈진영보다 훨씬더 빠르게 ORM을 통한 개발 요소를 내부에서 표준화하였고 통합하였습니다. -Entity FrameWork

그래서 어플리케이션 개발자가 ORM적용을 주도하려면 DB개발지식을 가지고 토론해야하기때문에 불편해지는 상황이 생길수 있습니다.

이것을 힘들게 주도하여 바꾸는것을 권장하지 않습니다.

언젠가 쓰일수 있으며, 왜 ORM은 우리회사에 적용이 어려운가란 주제는

RDB를 공부하는데 아주 좋은 주제가 될듯 합니다.

다음은 ORM 사용시 오해받는 몇가지 주제입니다.

• ORM의 쿼리는 통제가 안되고 느릴것이다. ==> TypeSafet한 방식의 쿼리빌드를 선택하고,표준쿼리를통해 성능문제를 해결하려고 합니다.
• ORM에서는 쿼리 최적화가 불가 ==> 네이티브 쿼리의 불편한점에대해 경고를 해줄뿐 JPA에서 날쿼리도 가능합니다.
• ORM은 쿼리 개발을 모르는 초짜가 사용하는 기술이다. ==> QueryDSL은 SQL을 이해못하면 람다식으로 SQL식을 풀어낼수 없으며, 쿼리작성보다 엔티티를 먼저 맞추는데 시간을 들입니다. 그리고 쿼리식과 람다식은 닯아있습니다. ORM에서 오히려 순차적 중복 쿼리 호출방식을 지양합니다.
• ORM은 ERD를 그려낼지 모르는 개발자가 사용하는 기술이다 - ==> 기존개발방식이 ERD설계된 관계를모르고, 조인남발 쿼리로 잘못된 집합체를통한 뷰어개발이 가능하지만, ORM에서 ERD관계를 맞추지못하면 빌드 조차 안되는 경우가많습니다.

외래키로 널허용이 금지된 1:1관계를 파악하고, JPA는 왜 자동으로 Inner Join을 걸게되는가?

JPA를 설계한 쿼리가 일반 쿼리개발자보다 일반적으로 똑똑하다란 것입니다.

대부분 쿼리로 개발한 개발자는 널허용여부에따라 왜 InnerJoin을 걸어야하는가에 대한 답을 빠르게 하지 못하지만

JPA는 놀랍게 그러한 표준적인 쿼리성능 빌드에대해 고민을 하였으며 외래키에 Null허용을 할경우 놀랍게도 InnerJoin을 사용하지 않았습니다. 

물론 실행계획을 반영하여 극단적인 쿼리튜닝이 필요해 DBMS가 제공하는 네이티브 쿼리가 필요한 경우 ORM은 도움되지 않습니다.

성능의 문제를 쿼리가 오브젝트를 관리하는 메시지중심으로 풀어갈수 있는 방법을 JPA가 제공해주지만 RDB와 어플리케이션이 가진 객체를

둘다 이해해야하는것으로 ERD와 UML의 불일치를 해결을하고 , 그것을 일치하여 성능문제를 해결하려는 시도는 

쿼리를 극단적으로 튜닝해야하는 주제처럼 둘다 어려운주제로..., JPA의 성능이 항상떨어진다라는것은 올바르지 않습니다.

DB용어를 사용하여 조급더 고급지게 접근해보겠습니다.

• DDL(Data Definitison Language)의 테이블 객체의 생성(Create),변경(Alert),삭제(Drop)등을 수행
• DML(Data Manipulation Language) : 스키마객체의 데이터를 Insert/Update/Select등을 할수 있는 명령어(표준화되어있어서 거의 공통)
• DCL(Data Control Language) : Commit,RollBack,SavePoint등을 할수 있는 명령어(DB종속적인 경우가 많음)

JPA-ORM은 기본적으로 DDL/DML/DCL을 모두 할수 있는 구조입니다.

이것은 ORM이해가 아닌 기존 RDB가가진 언어입니다. 접근 정책정의에 있어서 중요요소 3가지를

빠트리고 이야기가 진행되는경우가 많지만... 정책결정은 위 3가지를 포함해서 이야기되어야하는 항목으로 생각됩니다.

SP를 이용한 장점:

• SP를 통한 통제방식은 MSSQL과 상관없이 , DB접근 정책을 정하기 아주 단순/명쾌 해지기 때문입니다.
• 또한 쿼리품질을 SP를 통해 제어하고, 비지니스로직을 집합시키는데 용이합니다.
• 결국 DDL/DML/DCL 어플리케이션별로 세부적인 접근 정책이 필요없어지게 됩니다.
• 그리고 쿼리최적화를 통한 SP호출방식이 실행계획 성능 향상에 일반적으로 도움이 된다.

ORM을 이용한 장점:

• 고성능 분산처리 어플리케이션 설계를 위해서는 DML 특히 트랜잭션에 관련된 DCL이 가능해야함 ( Entity의 영속성및 Proxy개념 )
• SP내부에 작성되는 쿼리는 일괄적인 품질관리가 안되며, SP자체가 형상관리가 안되고 결국 SP는 이야기합니다. 나는 안쓰인다 고로 존재한다.
• 고성능 분산처리를 위해 트랜잭션에 어플리케이션이 안정적이고 더 효율적이게 관여할수 있는 개발방법이 많이 등장하였습니다.
• 인덱스를 걸고 실행계획을 안정적으로 유지하는것은 DBMS마다 약간의 차이가있고 그리고 그것은 비표준 SQL문 작성을 강요하며 일괄적으로 유지가 어렵습니다.

SP를 통한 DB개발에서 이야기하는 장점이 오늘날에는 단점이 된 케이스가 일부있고

서로 상반된 이야기를 하기때문에 풀어나가기가 어려운 주제임은 분명합니다.