Page History

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

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

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

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

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

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

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

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

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

• ORM의 쿼리는 통제가 안되고 느릴것이다. ==> TypeSafet한 방식의 쿼리빌드를 선택하고 , 쿼리최적화가아닌 방식을 사용합니다.
• ORM에서는 쿼리 최적화가 불가 ==> 네이티브 쿼리의 불편한점에대해 경고를 해줄뿐 JPA에서 날쿼리도 가능합니다.
• ORM은 쿼리 개발을 모르는 초짜가 사용하는 기술이다. ==> 테이블하나에서 수백가지의 검색쿼리 작성이가능합니다. 그리고 그것은 각각 다른 개발자가 작성을하여 SP화합니다. QueryDSL은 SQL을 이해못하면 람다식으로 SQL식을 풀어낼수 없습니다.
• ORM은 ERD를 그려낼지 모르는 개발자가 사용하는 기술이다 - ==> 기존개발방식이 ERD를 모르고 날쿼리로 잘못된 집합체로도 뷰어개발이 가능하지만, ORM에서 ERD관계를 맞추지못하면 실행 조차 안됩니다.

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개발에서 이야기하는 장점이 오늘날에는 단점이 된 케이스가 일부있고

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

JPA가 직접 SQL문을 수행합니다. 여기서 수많은 논쟁이 발생할수 있습니다.

• A : SQL문을 어플리케이션에서 Type세이프(QueryDSL)하고 효율적인 방법으로 사용할수 있는 방법을 도입하였으며 DB호출을 방지하기위해 분산처리시켰습니다. 그런데 작동을 안합니다.
• B: 직접쿼리는 쿼리튜닝에 관여할수 없으며 DBMS에서 관리할수 없으니, SELECT 권한이 없습니다.어플리케이션은 SP로만 사용해주세요 SP방식이 무조건 성능이좋습니다.
• A : 운영 데이터가 꼬인것같습니다. A,B테이블에서 X조건이되는 게 문제인듯보입니다. 다른사람이 만든 SP에서 뭔가 잘못된거같습니다. 데이터 검증부탁드립니다.
• B: 여러개발자의 SP개발 문제에 관여하기 어렵습니다. 직접 문제를 찾으십시오
• A : 형상관리가되는 어플리케이션을 통해 문제를 자동으로 찾고싶습니다. 어플리케이션에 Select권한을 주십시오
• B: 정책상 어플리케이션이 쿼리를 하면 안됩니다. 운영처리해야하니... 개인계정을 추가하고 임시 Select권한을 드릴테니 직접 문제를 찾으십시오
• A: 이문제를 찾는 SP를 작성하였습니다. 직접 호출하여 문제를 분석할테니 개인에게 SP실행권한을 주십시오
• B: 정책상 개발자에게 SP 실행권한을 줄수 없습니다. 정상 디플로이된 어플리케이션을 통해 실행하십시오

개발자가 직접 운영DB에 접근을 해야하는 문제와 ,어플리케이션은 SP로만 작성되어야한다란 문제에서 충돌 과정입니다.

다소 극단적으로 상황을 만들어 냈지만.....이것은 DBMS의 차이로 정책이 그렇게되어야 한다고 결론내리는 DBA분도 계십니다.

대략정리하면 MSSQL은 SP방식이 올바르고, 오라클은 SP안쓰는게 이득이다란 결정입니다.

하지만 전통적인 개발방식에서 그렇게 진행 되어 왔던것이며, DBMS의 차이는 아닙니다.

• MS개발진영에서는 SP를 관리하는 방식및 SP호출을 통한 개발통제방식으로 진행되어왔습니다. 배치는 DBMS스케쥴러의 SP방식을 고수했습니다.
• 오라클에서는 성능개선점을 쿼리튜닝에 포인트를 좀더 두었고, 배치처리는 SP가아닌 SQL을통한 어플리케이션 스케쥴에의한 부분처리방식을 택하였습니다.

그래서 어플리케이션에서 MSDB를 선택하면 SP를 사용해야하고 오라클을 사용하면 쿼리방식을 사용한 국내에서만 해당되는 관례일뿐입니다.

심지어 오라클은 SP를 사용할수 없고 , 오라클에서 SP는 아무 이득이없다라고 잘못생각하시는분도 많이 봐왔습니다.

SP를 사용한 개발의 장단점은 MSSQL이나 오라클이나 별반 차이가 없다란 것입니다.

SP개발방식또는 쿼리방식이 각각 자신의 개발팀및 DB유지차원에서 그때당시 가장 적합하다라고 판단한 로컬 정책일뿐입니다.

결코 오라클이나 MS가 결정한 사항이 아니란것입니다. 그리고 그 정책의 장단점은 현시점 맞지 않을뿐더러

그냥 현존하는 DBA가 전통적으로 유지했던 개발방식에 맞춰 DB를 그렇게만 관리했기때문에 바꾸기가 힘들다라고 정의를 해봅니다.

이것은 데이터중심적 개발적 방식도 아니고 DBA중심적 개발방식을 택하고 있다란 사실을 인지하는것입니다.

그럼 과연 MS에서는 SP방식을 제안하고 추천하였는지?

SP개발방식이 절대적으로 유리한지 MS 웹플랫폼에 사용되어지는 DB기술을 한번 살펴볼 필요가 있습니다.

Entity FrameWork : 궁극적으로 ORM을 추구하는 자바진영의 JPA/Hibernate 와 같은 녀석

EnterPrise Library: SQL/SP을 맵핑을 하는 JAVA의 Mybatis버젼

LINQ : JAVA의 QueryDSL에 대응

위 스펙은 모두 MS가 공식적으로 지원하고 있는 기술이며 최신 기술도 아닙니다.

MSDN에 있는 내용들이며..., ORM과 상관없이 Asp.net 개발하면서 자주 눈에 뛰었던 라이브러리들입니다.

JAVA에 비해 MS에서의 ORM 추가 사용은 아주 쉽다란것이며

JPA+QUERYDSL의 오픈진영과 다르게 MS가 주도적으로 LINQ와 함께10년전부터 ORM과 함께 외쳐왔던 기술입니다.

각각 진영의 ORM의 표준정립은 MS가 먼저 하였다란것입니다. 이것은 단지 오픈진영의 표준이 오래걸리는것의 차이일뿐이며

해외진영 엔터프라이즈급 웹에서는 JAVA의 ORM이 꾸준하게 성공을 거두고 있다란 것입니다.

기존에 운영중인 플랫폼을 굳이 무리해서 바꿀필요는 없지만, 만약 바꾸게 된다고 하면 JAVA↔C# 또는 ASP.net↔Spring 으로

전환하는것은 아무런 의미가 없습니다. 본질적으로 동일한 웹기술을 서로 가지고 있으며 ,

개발팀이 더 잘할수 있는 방식을 사용하면 됩니다.

하지만 기존 쿼리중심 개발방식에서 ORM방식으로 바꾸는것은 웹에서는 개발 플랫폼을 바꾸는 것보다

더큰 모험이 될것이며 가치가 있는 도전이 될것입니다.

https://msdn.microsoft.com/en-us/library/aa937723(v=vs.113).aspx