SQL vs ORM ?

@안근창 안녕하세요 근창님 저의 블로그에 관심있게 봐주셔서 감사해요!! 제가 놓친것도 있고 2편에 말하고 싶었던 ORM 의 장점의 맥락과 비슷한 부분을 잡아주신것도 있네요!. 'Clean Architecture' 책에서 나오는 설계에 의하면 비즈니스 로직을 DB SQL 같은 곳에 담는게 아닌, 코드에 녹이도록 가이드 하고 있지만, 저 방식은 사실 이러한 패러다임을 역행하는 느낌을 저도 지울 수는 없었어요. 어쩌면 제조업(MES) 의 특수성 일 것 같기도 하지만 복잡한 반도체 비즈니스 공정로직을 하나의 서비스에 코드로서 모두 심는것은 불가능하지 않을까 하던 고민을 한번 해봤었어요. 하나의 트랜잭션내에 많은 부하를 일으키지 않는 조그마한 CRUD 관점에서는 사실 성능 상에서도 말씀해주신 부분에서도 ORM이 더 좋은 merit 를 가져가고 저도 자주 사용합니다 ㅎㅎ 이번 글은 조회속도에 영향을 받는 OLAP 서비스에 좀 더 특화된 부분에서 , ORM 과 Raw SQL 의 실제 성능 차이가 어느정도로 발생하는지 한번 깊게 파본 내용이었습니다. Trade Off 관계를 생각하면 저도 승자는 없다고 생각해요. 다시한번 좋은 인사이트를 남겨주셔서 감사해요!!

@장진수 안녕하세요 답변 감사합니다 저는 클린 아키텍처가 맞다고 생각하고 헥사고날 아키텍처를 지향합니다. 물론 작은 사이드 프로젝트에서는 오히려 배보다 배꼽이 큰 오버헤드로 일정이 길어지는 악영향이 있었지만 말씀하신대로 복잡한 비지니스 로직에서는 더더욱 필요로 합니다. 약간 오버엔지니어링이 아닌가 싶을 정도로 복잡해지지만... 사람이 적응의 동물이라.. 또 익숙해지더군요.. 복잡해지면 엔티티가 또 수십개가 되기 때문에 이렇게 큰 경우에는 도메인 주도 개발(DDD)로 개발까진 아니더라도 이벤트 스토밍을 하시고 도메인/어그리게이트/엔티티로 나눠놓으시면 각 도메인 별 서비스들의 조합으로 구성하실 수 있습니다. 다만 저도 대형 포탈과 커머스 경험 뿐이고 제조업의 경험은 없기 때문에 제조업의 특수성은 모른다는 전제로 말씀드립니다^^ 제가 다루는 서비스에서는 OLAP에서는 SELECT만 하게 되므로 트랜잭션을 read-only로 해놓는 것으로도 충분히 해결되었습니다. (레코드 갯수는 5천만~7천만 이쪽 저쪽) 현재 OLAP 트랜잭션이 read-only인지 한 번 확인 해주세요 그리고 OLTP의 경우라도... ORM으로 도저히 답이 안나오는 (일간 정산 배치 등;) 부분은 저도 결국 그냥 sql로 처리했습니다^^ 그래서 또 OLAP/OLTP 안에서도 또 case by case가 있는 것 같습니다

@안근창 크.. 능력자이신것 같은 스멜이 물씬 풍기는분이군여. 저도 클린 아키텍처, 헥사고날 아키텍처를 지향하는 편이라 덕분에 좋은 인사이트 얻어갑니다 (꾸벅)