Page History
...
SQL문은 약간의 조건만 바뀌어도 쿼리를 새롭게 작성해야하며( 똑똑한 공통 SQL빌드가 없다고 가정)
그리고 약간의 기능차이로 인해 매번 새로운 SP를 DBMS에 등록하고 관리해야합니다.
형상관리가 비교적 쉽지 않은 SP를 장기간 운영하면, 심각하게는 30%이상이 사용되지 않는 코드가되며
그누구도 사용되지 않는 코드를 정리하지 못한채 존재하게 됩니다.
| Expand | ||
|---|---|---|
| ||
JPA가 직접 SQL문을 수행합니다. 여기서 수많은 논쟁이 발생할수 있습니다.
개발자가 직접 운영DB에 접근을 해야하는 문제와 ,어플리케이션은 SP로만 작성되어야한다란 문제에서 충돌 과정입니다. 다소 극단적으로 상황을 만들어 냈지만.....이것은 DBMS의 차이로 정책이 그렇게되어야 한다고 결론내리는 DBA분도 계십니다. 대략정리하면 MSSQL은 SP방식이 올바른거임올바르고, 오라클은 SP안쓰는게 올바른거임 본질적인 차이는 이득이다란 결정입니다. 하지만 전통적인 개발방식에서 그렇게 진행 되어 왔던것이며, DBMS의 차이는 아닙니다.
그래서 어플리케이션에서 MSDB를 사용하면 선택하면 SP를 사용해야하고 오라클을 사용하면 쿼리방식을 사용해야했습니다.사용한 국내에서만 해당되는 관례일뿐입니다. 심지어 오라클은 SP를 사용할수 없고 , 오라클에서 SP는 아무 이득이없다라고 잘못생각하시는분도 많이 봐왔습니다. SP를 사용한 개발의 장단점은 MSSQL이나 오라클이나 별반 차이가 없다란 것입니다. SP개발방식또는 쿼리방식이 각각 자신의 개발팀및 DB유지차원에서 그때당시 가장 적합하다라고 판단한 로컬 정책일뿐입니다. 이것은 데이터 중심적 개발도 아니고... DBA중심적 개발방식입니다. 결코 오라클이나 MS가 결정한 사항이 아니란것입니다. 그리고 그 정책의 장단점은 현시점 맞지 않을뿐더러 그냥 현존하는 DBA가 전통적으로 유지했던 개발방식에 맞춰 DB를 그렇게만 관리했기때문에 바꾸기가 힘들다라고 정의를 해봅니다. 이것은 데이터중심적 개발적 방식도 아니고 DBA중심적 개발방식을 택하고 있다란 사실을 인지하는것입니다. MS진영을 다시 한번 살펴보겠습니다. 그럼 과연 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방식으로 바꾸는것은 웹에서는 개발 플랫폼을 바꾸는 것보다 더큰 모험이 될것이며 가치가 있는 도전이 될것입니다.Entity FrameWork : https://msdn.microsoft.com/en-us/library/aa937723(v=vs.113).aspx |
...