Page History
...
어플리케이션 레벨에서 쿼리에관련된 TestCase 작성을 쉽게하고 또한 실제 작동되는 SQL문도 체크할수 있습니다.
소모적 반복적 SQL문 작성시간을 줄이고, 수많은 케이스를 유닛테스트로 전환될수 있을 가능성을 확인할수 있습니다.
있으며
이것은 데이터중심에서 메시지중심으로의 설계를 가능하게합니다.
SQL문은 약간의 조건만 바뀌어도 쿼리를 새롭게 작성해야하며( 똑똑한 공통 SQL빌드가 없다고 가정)
그리고 약간의 기능차이로 인해 매번 새로운 SP를 DBMS에 등록하고 관리해야합니다.
형상관리가 비교적 쉽지 않은 SP를 장기간 운영하면, 심각하게는 30%이상이 사용되지 않는 코드가되며
그누구도 사용되지 않는 코드를 정리하지 못한채 존재하게 됩니다.
| Expand | ||
|---|---|---|
| ||
JPA가 직접 SQL문을 수행합니다. 여기서 중요한 논쟁점이 생길수 있습니다. Insert/Update때 트랜잭션은 누가 처리하는가? 왜 위험하게 어플리케이션이 직접 SQL문을 날리는가? 기존 개발정책이 SP만 사용하고, 트랜잭션처리가 SP내에서만 있어야된다란 정책이 있다고하면 수많은 논쟁이 발생할수 있습니다.
개발자가 직접 운영DB에 접근을 해야하는 문제와 ,어플리케이션은 SP로만 작성되어야한다란 문제에서 충돌 과정입니다. 다소 극단적으로 상황을 만들어 냈지만.....이것은 DBMS의 차이로 정채이 그렇게되어야 한다고 결론내리는 DBA분도 계십니다. MSSQL은 SP방식이 올바른거임, 오라클은 SP안쓰는게 올바른거임 본질적인 차이는
그래서 어플리케이션에서 MSDB를 사용하면 SP를 사용해야하고 오라클을 사용하면 쿼리방식을 사용해야했습니다. 이것은 데이터 중심적 개발도 아니고... DBA중심적 개발방식입니다. 결코 오라클이나 MS가 결정한 사항이 아니란것입니다. 사실 JAVA진영은 오픈진영이기때문에 표준으로 자리잡는데 까지 시간이 오래걸립니다. JAVA ORM 스펙정의는 10년이상 진행해왔고..,이제는 안정적으로 자리를 잡았으며 JPA로 완성단계이 이르렀습니다. MS도 살펴보면 LINQ와 함께 ORM(Entity라이브러리) 의 스펙정의및 라이브러리화는 이미 오래전에 진행되었고 Asp.net에 EnterPrise Entity 를 자연스럽게 통합하고 Asp.net 개발자는 SP개발을 EnterPrise 라이브러리를 통해 SP맵핑을 사용해왔습니다. 그렇기때문에 MSSQL은 SP로만 사용해야해 라고 오판하고 있습니다. 사실 MS진영에 ORM을 LINQ와 함께 사용하는것은 JAVA에 JPA를 추가하는것보다 훨씬 쉽습니다. 이미 내장화가 되어있으니까요... EnterPrice Entity 는 말그대로 ORM을 구현하겠다란 네이밍입니다. https://msdn.microsoft.com/en-us/library/aa937723(v=vs.113).aspxJPA는 SP와 상호작용도 가능하지만, 이 비율이 100%일때 이점이 있는가? 에대해서는 고민을 해야할듯보입니다. |
실행계획 조사하기
Trace된 SQL문을 그대로 복사하여, 실행계획을 조사합니다. 매번 이러한 과정을 거칠필요는 없을듯보이며
...
| Warning |
|---|
논란의 소지가 있지만, JPA를 학습하면서 느낀점입니다.
SPRING BOOT를 SPRING BOOT을 통해 자연스럽게 JPA를 권장해서 접근이 쉬운기술이다라고 접근을 하였는데오판을 하였지만 기존에는 일반적으로 성능의 대부분의 문제를 쿼리튜닝및 데이터중심적 설계로 해결을 하였습니다. 하지만 ORM에서 성능문제는 어플리케이션에서 OOP의 영속성을 관리해야하며 최종 RDB에 저장되기때문에 성능 해결포인트가 다른곳에 있으며 이것을 이해하는것은 RDB와 JPA내부에서 작동되는것을 둘다 알아야됨을 의미합니다외래키가 없는 복합키 맵핑이란 문제를 ORM으로 풀려고 하다보니 더 깊은 RDB의 공부가 필요했습니다. http://wikiwonwoo.webnoriml/index.comphp/pages/viewpage.action?pageId=10387481post/997 |
이 부분은 개념과함께 구체적인 사용사례가 필요한 부분이며, 샘플을 좀더 준비할예정입니다.
...