여러분에게 기술 트렌드 어떻게 생각하시는지 궁금해서 몇글자 적어봅니다.
김상훈
제가 알고 있기에는 세계적으로는 HIbernate가 대세이고
한국은 IBatis가 대세 정도로 알고 있습니다.
물론 제 개인적인 생각일수도 있을것 같습니다.
제 생각에는 Hibernate 프레임웍의 특성을 보면 비교적 잘 설계되고 복잡도가 상대적으로 높은편인것 같고,
반면에 IBatis는 기능은 간단하지만 SQL을 직접쓰기가 편리하고,
많은 학습없이 쉽게 사용할 수 있는것 같습니다.
그래서 전 여러분은 이 두가지 프레임웍크에 대한 생각을 듣고 싶습니다.
여러분이 이 두가지 프레임웍을 선택 하실 기회가 되거나 선택하셔야 한다면 어떤것을 왜 선택하시겠습니까?
신승한
iBatis는 2년 정도 사용했습니다만 효용성으로 따져서는 Hibernate가 압도적인거 같습니다.
진짜 개발자의 칼퇴근을 도와주는 도구는 Hibernate라고 생각되네요.
Hibernate가 초기 학습비용이 크지만 개발자 전원이 모두 알아야 할 필요는 없다고 생각됩니다.
몆몆 사람들이 Db설계와 매핑을 해준다면 나머지 분들이 도메인 설계를 하면 됩니다.
문제는 Hibernate 매핑을 다루는 사람이 고객의 신뢰와, DBA급의 권한과, Hibernate를 이해하며, 클래스설계에도 익숙해야 할듯 한데
한국에서는 그게 쉽지 않을듯 하네요.
YounJung Park
초기에 Hibernate도 고려해봤는데 아직 사용법에 익숙하지 않고 여러개의 테이블을 조인해야 되는 상황에다
또 다양한 통계쿼리를 직접 작성해야 될 경우가 많아서 iBatis를 선택했습니다.
iBatis만 선택해도 어느정도의 장점을 누릴수 있지만 진정한 OR Mapping의 장점을 얻으려면 Hibernate가 해답일 거라는
생각이 드네요.
물론 DB설계가 깔금해야 되고 관련 framework에 대한 지식이 있다라는 전제가 깔려야 겠지요.
OR Mapping과 Sql mapping은 완전 개념이 틀린 것 같습니다.
--
=============================
Blog : http://avatar72.tistory.com
E-mail: yjp...@enz.co.kr
MSN : avat...@dreamwiz.com
NateOn : evas...@nate.com
Google talk: handso...@gmail.com
박성철
http://groups.google.com/group/ksug/browse_frm/thread/b174407336bb53/e09c18286545bc0d
그런데 이 둘이 비교 대상일까요? ^^
sanghoon kim
박성철
저도 하이버네이트 쓰시는 분들이 어떻게 쓰는 지 궁금하네요.
진짜 ORM으로 쓰시는 지.. 아니만 DB 연결 도구로 쓰시는 지...
On 7월6일, 오후5시14분, sanghoon kim <javamix....@gmail.com> wrote:
> 둘을 비교하고 꼭 올린것은 아닌데 제 질문이 잘 못 되었나 보네요.
>
> 프로젝트 선택시 둘을 같이 사용하는 프로젝트는 없을거라는 의문점에서 적어 보았습니다.
>
> 그러다 보니 마치 둘이 똑 같은 기능을 하는 서로 다른 프레임으로 보여졌나 보네요.
>
> 둘을 비교하고 하는것이 요점이 아니란 것을 말씀드립니다.
>
> 단지 여러분이라면 어떤 것을 선택하시겠냐는 질문이였습니다.
>
> 2009년 7월 6일 오후 5:03, 박성철 <gyu...@gmail.com>님의 말:
>
> > 얼마 전에 비슷한 논의가 있었습니다.
>
> >http://groups.google.com/group/ksug/browse_frm/thread/b174407336bb53/...
김진
CoC 스타일로 RowMapper와 SqlParameterSource를 쓰면 웬만한 SQL 매핑 문제는 해결할 수 있고, 동적
쿼리 작성 부분만 잘 잡아놓으면 iBatis가 제공하는 거의 대부분을 Spring JDBC로 커버할 수 있을 것 같습니다.
iBatis는 쿼리를 xml 파일로 따로 빼놓아서 일종의 추상화를 시키려고 하는 데 이 부분은 쓸데없는 오버헤드가 되기 쉽지 않
나 생각합니다.
On 7월6일, 오후3시55분, 김상훈 <javamix....@gmail.com> wrote:
Sewon Ann
근데 한가지 궁금한게, Hibernate 를 SI 프로젝트에서도 사용하나요?
회사 내부 프로젝트나 자체 솔루션 개발 같은 경우 개발 조직이 공부해서 Hibernate 를 사용하면 되겠지만,
(Hibernate 에 대한 교육 비용이 존재하는 것은 모두 공감하고 계시다고 생각합니다.)
SI 프로젝트에 투입된 외주 개발자들에게 비용과 시간까지 들여가며 Hibernate 를 교육시키긴 어렵지 않나 생각합니다.
또한 iBatis 같은 경우 XML 이 따로 떨어져 있으므로 엉성한 query 를 잡아내기가 약간은 더 수월한데
Hibernate 의 경우 소스를 일일이 까 봐야 알 수 있을 것으로 생각하고, 또한 까봐도 잘 알아보기가 힘들것 같아요.
제 경우 6개월 정도 되는 프로젝트 표준을 잡을 때 Hibernate 는 위의 이유 등으로 아얘 처음부터 제외를 하고 시작했습니다.
개발자 구할 때 "Hibernate 가능자" 를 조건에 내걸었다면야 가능하겠지만, SI 프로젝트가 많은 우리나라 상황에서는
Hibernate 가 확산되기 어렵다고 생각합니다. 혹시 SI 프로젝트에서 Hibernate 를 적용해 보셨나요? 그런 경험이 있으셨다면 경험담을 듣고 싶네요.
안영회
근데 한가지 궁금한게, Hibernate 를 SI 프로젝트에서도 사용하나요?
회사 내부 프로젝트나 자체 솔루션 개발 같은 경우 개발 조직이 공부해서 Hibernate 를 사용하면 되겠지만,
(Hibernate 에 대한 교육 비용이 존재하는 것은 모두 공감하고 계시다고 생각합니다.)
SI 프로젝트에 투입된 외주 개발자들에게 비용과 시간까지 들여가며 Hibernate 를 교육시키긴 어렵지 않나 생각합니다.
또한 iBatis 같은 경우 XML 이 따로 떨어져 있으므로 엉성한 query 를 잡아내기가 약간은 더 수월한데
Hibernate 의 경우 소스를 일일이 까 봐야 알 수 있을 것으로 생각하고, 또한 까봐도 잘 알아보기가 힘들것 같아요.
제 경우 6개월 정도 되는 프로젝트 표준을 잡을 때 Hibernate 는 위의 이유 등으로 아얘 처음부터 제외를 하고 시작했습니다.
유지보수 담당자와 다른 경우라면, 더군다나 누가 들어올지 모르는 프로젝트라면 Hibernate 적용은 엄두도 못낼 일이죠.
개발자 입장에서 그다지 필요성을 느끼지 못하는 EA니 TRM 등을 논하는 이유나 '변화관리' 등의 이슈가 무관하지 않은 내용인데...
그런 이야기를 꺼내지 않더라도 종종 책임감 없는 인사가 개인적인 선호(?)로 기술만 선정해놓고 제대로 가이드도 하지 못해 프로젝트에 고통을 심어놓고, 시스템엔 버그를 심어놓고 나가는 경우가 있습니다.
Toby Lee
박성철
제 생각에 하이버네이트의 전체 학습 비용이 ibatis를 배우는 다 비용보다 크다고 생각하지는 않습니다.
다만 사람들이 ibatis를 다 알고 쓰지 않는 다는 거...
아마 대부분 SI 개발자들은 ibatis의 dynamic sql이나 cache 기능도 모를 거에요.
결과를 객체에 담지도 않을 거고요.
결국 이미 알고 있는 SQL 지식을 활용해서 뭔가 앞선 기술(처럼 보이는) 뭔가를 쓴다는 이미지를 노리는 것 아닐지...
사실 생짜 JDBC 작업을 하는 것 보다는 ibatis가 편하니까요. 다만 우리에게는 spring jdbc가 있지요. ㅎㅎ
> - 하이버네이트를 안쓰는 이유가 여러 테이블 조인이나, 리포트(통계)쿼리가 있기 때문이라는 것이 과연 타당한 이유인가요?
하이버네이트 안 쓰는 이유로 이런 이유는 별로 들어보지 못했습니다.
> HQL이 SQL에 비해서 뭐가 어렵나요?
사실 별로 어렵지 않지요. 다만 이미 개발자들이 SQL은 친숙한데 HQL은 새로 배워야 한다는 것이 문제지요. SI는 프로젝트
는 파견 개발자가 대부분인데 이 친구들이 참 대책없는 경우가 많습니다. struts나 spring의 아주 기본 내용만 교육해도
그 걸 이해 못해서 버벅이는 일이 많지요.
hibernate가 native sql로 쿼리할 수 있는 기능도 가지고 있지만 그거 설명하면 10명 중 한두명 이해하면 다행일
것 같아요.
사실 전 ibatis가 세상에 없었다면 참 좋았겠다는 생각입니다. 꼭 hibernate를 써야만 하는 건 아니지만 분명히
jdbc를 직접 쓰는 것 보다 hibernate 같은 orm을 쓰면 비용이 훨씬 줄어드는 임계점이 있는데 ibatis가 그 임계
점을 훨씬 뒤로 밀어버린 것 같아요. 기존에 습득한 기술을 우려 먹을 수 있는 기간이 늘어나는 거죠.
제가 hibernate를 쓰지 않는 상황이 아쉬운 건 단순히 hibernate라는 좋은 기술을 쓰지 못하기 때문이 아니라 ORM
의 보급이 늦어짐과 동시에 객체지향 기술도 보급이 되지 못하는 것 아닌지 생각이 들어서 입니다.
On 7월6일, 오후8시00분, Toby Lee <tobyi...@gmail.com> wrote:
> 이런 얘기가 나오면 항상 질문하시고 싶은 두가지가 있습니다.
> - 하이버네이트는 정말 학습비용이 높나요?
> - 하이버네이트를 안쓰는 이유가 여러 테이블 조인이나, 리포트(통계)쿼리가 있기 때문이라는 것이 과연 타당한 이유인가요?
>
> 저는 둘 다 아니라고 봅니다.
>
> 일반 DBA와 같은 역할을 해주는 하이버네이트의 매핑 담당자가 있다면 개별 개발자들은 별로 학습할 게 없습니다. 하이버네이트 매핑이
> 만들어져 있다면 90%이상의 쿼리들은 자바도 알고 SQL도 아는 개발자라면 1-2일 교육이면 충분히 다 작성합니다. HQL이 SQL에
> 비해서 뭐가 어렵나요? 게다가 하이버네이트의 튜닝은 개발 후 별도로 해도 그만이니까 오히려 초보자들이 덜 부담을 가지고 개발도
> 가능합니다. 어짜피 초대형 DB의 초고성능 쿼리가 필요한 상황이라면 SQL도 DBA가 미리 작성을 해주고 그것을 가져다 사용하는
> 식일테니까, 하이버네이트도 HQL이랑 최적화된 매핑 만들어서 개발자들에게 제공하면 됩니다.
>
> 나머지 10%의 리포트 쿼리나 DB의 특수한 기능을 사용하는 쿼리도, 그냥 하이버네이트의 Native SQL 쿼리매핑을 사용해서 SQL
> 그대로 쓰면 됩니다. 하이버네이트 안에서 일반 SQL을 사용할 수 있게 된 것은 언제부터인지 기억도 안날만큼 오래전부터 지원됐습니다.
> iBatis만큼 편리하게 Native SQL/XML-Entity(또는 DTO) 매핑도 해줍니다. 당연히 Stored Procedure도
> 호출해서 사용할 수 있습니다.
>
> 70% 이상의 쿼리가 리포트성 조회 쿼리로만 이루어진 분석전용 시스템이라면 그때는 하이버네이트를 쓰는 장점이 없습니다. 그 외에는
> 기술적으로는 하이버네이트를 안 쓸 이유가 없다고 봅니다.
>
> 2009/7/6 안영회 <ahnyoung...@gmail.com>
Toby Lee
> - 하이버네이트는 정말 학습비용이 높나요?
제 생각에 하이버네이트의 전체 학습 비용이 ibatis를 배우는 다 비용보다 크다고 생각하지는 않습니다.
다만 사람들이 ibatis를 다 알고 쓰지 않는 다는 거...
아마 대부분 SI 개발자들은 ibatis의 dynamic sql이나 cache 기능도 모를 거에요.
결과를 객체에 담지도 않을 거고요.
> - 하이버네이트를 안쓰는 이유가 여러 테이블 조인이나, 리포트(통계)쿼리가 있기 때문이라는 것이 과연 타당한 이유인가요?
하이버네이트 안 쓰는 이유로 이런 이유는 별로 들어보지 못했습니다.
> HQL이 SQL에 비해서 뭐가 어렵나요?사실 별로 어렵지 않지요. 다만 이미 개발자들이 SQL은 친숙한데 HQL은 새로 배워야 한다는 것이 문제지요. SI는 프로젝트
는 파견 개발자가 대부분인데 이 친구들이 참 대책없는 경우가 많습니다. struts나 spring의 아주 기본 내용만 교육해도
그 걸 이해 못해서 버벅이는 일이 많지요.
hibernate가 native sql로 쿼리할 수 있는 기능도 가지고 있지만 그거 설명하면 10명 중 한두명 이해하면 다행일
것 같아요.
사실 전 ibatis가 세상에 없었다면 참 좋았겠다는 생각입니다. 꼭 hibernate를 써야만 하는 건 아니지만 분명히
jdbc를 직접 쓰는 것 보다 hibernate 같은 orm을 쓰면 비용이 훨씬 줄어드는 임계점이 있는데 ibatis가 그 임계
점을 훨씬 뒤로 밀어버린 것 같아요. 기존에 습득한 기술을 우려 먹을 수 있는 기간이 늘어나는 거죠.
제가 hibernate를 쓰지 않는 상황이 아쉬운 건 단순히 hibernate라는 좋은 기술을 쓰지 못하기 때문이 아니라 ORM
의 보급이 늦어짐과 동시에 객체지향 기술도 보급이 되지 못하는 것 아닌지 생각이 들어서 입니다.
강명성
--
매일 행복한 시간 되시길 바랍니다...^^
Sanghyuk Jung
윤성한
Sewon Ann
sql 들어가면서 나름 OOP 개념으로 의욕적으로 설계를 하다가 깨지는 경향 (껍데기뿐인 모델 등등) 이 있다, 그리고 Hibernate 와 같은 ORM 도구를 "잘" 활용할 경우 OOP 적으로 좀 더 탄탄한 설계를 할 수 있다고 하는 글은 본 것 같은데 절차지향과 연관하여 이야기 하신 것은 잘 모르겠어요. 앞부분을 이해를 하지 못하여, 뒷 단락에 하신 말씀도 이해가 되지 않습니다. 절차지향보다는 OO - relation DB 컨셉의 짬뽕이 문제가 아닐까 해요.
다시 되돌아와서 ORM 도구를 잘 활용하면 더 OOP적으로 좋은 설계를 이끌어 낸다는 점에는 동의합니다.
박성철
체지향에 익숙하지 않은 것과 관계 있다고 생각이 듭니다.
이건 사실 제가 iBatis를 사용해서 쿼리 결과를 객체에 담는 방법을 개발자들에게 설명하면서 받은 질문 때문에 알게 된 건데
요.
RDBMS에서는 DB의 table 평면 공간에 배치되어 있고 서로 동등한 수준에서 관계를 맺는 구조이고 객체 지향에서는 여러 클
래스들이 상속이나 구성을 통해서 관계를 맺는 구조인데 이 두 구조 간의 차이가 생각보다 큰 것 같습니다.
간단히 말해서 RDBMS에서 SQL을 사용하면 이런 저런 테이블을 어떻게 복잡하게 조인해서든 원하는 컬럼 한 두개를 평면적으로
읽어 올 수 있는데 객체를 사용하면 입체적인 구조로 담아와야 한다는 거죠. 뭔가 미리 계획을 잘 세워야 하고 거추장스럽다는 인상
을 갖는 듯 했습니다.
On 7월7일, 오후1시22분, 윤성한 <yunsung...@gmail.com> wrote:
> 좀더 진실해지자면,
> Hibernate를 어렵게 느끼는것은 객체지향 프로그래밍에 익숙하지 않아서가 아닐까요?
> iBatis가 쉽게 느껴지는건 내가 좀더 절차지향을 편하게 느껴지는 습관 때문일거라는 생각 입니다.
>
> 그러면 사실 나는 OOP가 가능한 JAVA를 사용하면서 절차지향적인 면을 더 편하게 느끼고 있는 것입니다.
> 앨런 홀럽의 말처럼, JAVA를 절차지향적으로 작성하면 JAVA를 사용할 이유가 없습니다.
> 차라리 절차지향 언어로 작성하는것이 더 효율적일지도 모릅니다.
>
> 2009년 7월 7일 오전 8:15, Sanghyuk Jung <bene...@gmail.com>님의 말:
>
> > 초점은 다르지만, 어제 읽은 아래 기사도 생각이 났습니다.
>
> > no sql? :
> >http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=57298
>
> > 위의 기사는 주로 hadoop 같은 대용량 처리 쪽의 이야기를 하고 있기는 합니다. 그래도, 아마도 빅테이블 기반의 저장소에 JPA나
> > JDO스펙을 지원하는 google app engine을 보면, 웹어플리케이션 개발자에게도 sql 없는 개발이 대세가 될 날이 언젠가는
> > 오지 않을까하는 생각도 드네요.
>
> > 그나저나 위의 기사에 인터뷰한 사람중에 자비에르 솔테로가 스프링소스의 CTO라고 되어 있네요. 찾아보니 전에 하이퍼닉 이라는 곳의
> > CEO였었던 것같은데, 하이퍼닉 HQ라는 네트워크 모니터링 솔류션 같은 것을 만든 것 같습니다. 스프링소스가 확실히 미들웨어 시장까지
> > 넘어가려는 느낌을 여기서도 받았다면 오버일까요? ^^;
>
> > 2009년 7월 7일 오전 12:17, 강명성 <joyto...@gmail.com>님의 말:
>
> > 전 솔직히 Hibernate는 어렵습니다.
> >> 특히나 쿼리를 생성하기 위한 'Criteria' 사용법이 너무 어렵습니다. 일반적인 조인관계는 그렇다쳐도
> >> 사용하기 위해선 맵핑 설정을 충분히 고려해서 사용해야하고 차근차근 개발하기에는 무리가 있더군요.
> >> iBatis는..초기에 조금 사용해봐서 고급기능까지는 안해봤지만, 어렵게 접근은 안해도 되더군요.
>
> >> 그래서 앞으로는 좀더 Hibernate를 공부하면서 Spring JDBC를 사용해보려 합니다. ㅎㅎ
>
> >> 2009년 7월 6일 오후 9:54, Toby Lee <tobyi...@gmail.com>님의 말:
> ...
>
> 추가 정보 >>
신승한
단순히 join때문이 아니라 HQL을 토드나 오렌지에서 테스트해 볼 수 없어서 싫어하시는게 아닐까요?
전 프로젝트에서 개발자분들은 HQL보다는 flush같은걸 잘 모르셔서 문제가 생기더군요.
박성철
위에서 토비님이 질문하신 것 중 두번째에서 제가 join은 별 문제 없는 것 같다고 말을 하고 보니 이런 생각이 나더라고요. 그
래서 말씀드려 봤습니다. ^^
HQL이야 LOG에 찍히는 sql 구분 사용해서 토드(이 비싼 놈)에서 돌려보면 되기는 하지만 일단 ORMap 담당자가 이런 일
을 해주면 개발자들은 신경 안 써도 되겠죠.
ORMap 담당자는 필수 같아요. ^^
> ...
>
> 추가 정보 >>
Toby Lee
Sanghyuk Jung
신승한
Sewon Ann
TOAD 등 비싼 도구를 사용하면서 그 많은 기능을 쓰지 않고 단순히 쿼리만 때리는 것이라면 이런 다른 무료 도구를 사용하는 것이 낫겠지요. (게다가 대부분 불법으로 사용하고 계시니...)
http://www.oracle.com/technology/global/kr/products/database/sql_developer/index.html
근데, 조큼 무겁습니다.
--
---------------------------------------------------
Sewon Ann
Chief Staff Consultant @ SolutionLink
안영회
정보 시스템 개발을 할 경우 시스템 핵심정보라 할 수 있는 "모델"은 주로 ERD에 녹아듭니다. 현장에서 객체 모델 필요성(?)을 주장한지 5년째이던 2007년 즈음에 현실을 인정했습니다. 넓은 강당에서 고객과 ER 모델러가 커다란 ERD를 펴놓고 격론을 벌이는 모습을 보고서 단념했죠. 과연 객체 모델을 가지고 키맨 사이에 논쟁을 벌이는 날이 언제 올까요? 일회성으로 진행하는 프로젝트에선 요원할 일일 지도 모릅니다.
성철님이 말씀하신 바대로 능력(?)을 전혀 가늠할 수 없는 외주 개발자가 무척 많습니다. 거기에 연차까지 많으면 설득에도 오랜 시간과 노력이 필요합니다. 그런 분을 이끌고 촉박한 시간 안에 프로젝트를 하는데 Hibernate를 쓰자고 하는 일은 헛심쓰기에 가까운 경우가 많습니다. 특히, 업무 설계가 엉성한 경우는 Sub-query와 UNION 없이는 화면 하나도 구현이 불가한데, 이런 경우 굳이 Hibernate를 도입이 주는 이점이 별로 없습니다.
Toby Lee
안영회
본질은 SI 프로젝트에서 주로 형식적인 부분과 절차적인 면은 중요시하지만, 내용에 해당하는 설계 자체에 대해서는 심각하게 다뤄지지 않는다는 점이죠. 외주 개발을 하는 SI 특성상 시스템을 사용하는 고객사 환경을 감안하지 않을 수 있습니다. 이를 위해 EA니 ITA 등을 논합니다. 수 년전부터 금융, 공공 등을 필수로 수행을 했죠. EA 안에서도 DA와 AA는 두드러진 연계점을 찾아보기 힘들더군요.
ERD는 데이터에 대한 정적인 뷰이기 때문에 실제 최종 사용자가 애플리케이션을 사용하는 시점에서 어떻게 데이터를 쓰는지. 가령, 어떻게 묶여서(가령 객체 형태로) 쓰이는지,수정이나 노출(조회) 빈도는 어떤지 등등 동적인 측면에 대해서도 충분히 고민을 해야 합니다. 만일, 이런 내용을 협의하고 고민하고, 그에 따라 시스템 속성을 변경할 필요가 있다면... 객체모델(UML로 그렸든.. 사람들 머리속에 있든)은 강력한 도구가 될 것입니다. 이런 곳에서라면 Hibernate는 정말 좋은 솔루션이라고 생각합니다. 그리고, 추후 그럴 가능성이 있는 곳이라면 학습 비용이나 변화에 대한 저항이 존재하더라도 충분히 대가를 치를 가치가 있겠죠.
설계 하면
- UML로 유스케이스부터 클래스다이어그램 기계적(?)으로 그린다거나
- 화면 설계에 이벤트만 달아놓으면 개발자가 알아서 한다고 생각하는
Toby Lee
박성철
ORM이 ERD 구조를 더 충실하게 유지한다고 하셨는데 맞습니다. 그런데 그런 특성이 ORM 도입을 힘들어하는 이유가 되는 것
같습니다.
우리나라 개발자들을 결과를 빨리 얻기 원하는 것 같습니다.
쿼리 하나 날려서 원하는 결과를 얻고 이 결과를 기계적으로 화면 단에 전달에 표시하기를 원하는 거죠. Data가 구조화된 상태
로 관리되는 것은 DB로 충분하지 굳이 메모리에까지 구조화된 상태로 가지고 오기를, 그래서 그 자료를 다시 어떤 로직으로 처리하
기를 원하지 않는 것 같습니다.\
데카르트 곱이 ERD의 구조를 깨트린다고 하셨는데 데카르트 곱의 결과를 가지고 어떤 처리를 할 것이 아니라 그것 자체가 결과라
면 사실 그런 구조 파괴가 문제되지는 않으니까요.
저는 이렇게 SQL에 대부분의 주요 로직이 들어가고 Java 코드는 단순히 인자를 전달하고 결과를 반환하는 일을 주로 하는 방
식의 개발 관행이 바뀌지 않는다면 ORM은 일할 양이 늘어나는 번거로운 기술로 받아들여질 듯 합니다.
On 7월7일, 오후4시22분, Toby Lee <tobyi...@gmail.com> wrote:
> RDB의 join만큼 기껏 설계한 ERD의 가치를 떨어뜨리는 것도 없다고 봅니다.
>
> 1:n을 join해서 한방에 가져오면 catersian product에 theta-join이 일어나 1:n의 릴레이션의 의미는 사라진
> 전혀 새로운 포맷을 가진 직관적이지 않은 결과가 돌아옵니다. 과연 그게 이해하기 쉬운 것인가요? 차라리 ERD에 나타난 엔티티 릴레이션의
> 구조대로 1:n의 관ㄱ를 유지해서 가져오는 하이버네이트와 같은 ORM이 ERD의 개념을 더 충실하게 나타내고 있다고 봅니다.
>
> 서브쿼리건 UNION이건 어짜피 SQL을 쓰나 Hibernate를 쓰나 쿼리작성 복잡도는 비슷합니다. 차라리 join의 갯수가 증가하면
> HQL이 SQL보다 훨씬 이해하기도 편하고, 역시 ERD에도 잘 부합됩니다.
>
> 구지 ORM의 특징이라고 하는 상속개념도 ERD에서 다 나타납니다. 그걸 물리적인 스키마로 표현하면 명시적으로 드러나지 않을 뿐이지,
> 원래 ERD에 있던 개념이 사라지는 것은 아닙니다. 하이버네이트가 ORM으로 성공한 이유는 백그라운드의 RDB를 무시하지 않고, 그
> 특징을 적극 활용하면서 프로그래밍 인터페이스 적인 측면을 강조했기 때문이지, 무슨 RDB의 ERD설계와 개념을 제치고 다른 걸 들고
> 나와서가 아닙니다. 하이버네이트를 마치 ODB처럼 생각하는 것은 완전 잘못된 이해입니다. 하이버네이트는
> RDB에 최적화된 또다른 접근방법의 하나일 뿐입니다. 테이블과 인덱스로 구성된 RDB에 SQL이라는 추상적인 인터페이스를 도입한 것과
> 다를바 없다고 봅니다.
>
> 이미 익숙한 기술을 고집해서 새롭고 보다 나은 기술에 저항했던 것은 ISAM에서 RDB로 넘어올 때도 마찬가지였고, 4GL을 도입할
> 때도, 자바가 메인스트림에 등장했을 때도, 웹 프로그램이 주류가 되려고 할 때도 마찬가지였습니다. 가치를 아는 사람들이 늘어가고
> 언젠가 임계점을 넘으면 ORM이나 post-RDB 기술이 SQL을 밀어내고 주류가 될겁니다. 아마 그때까지는 "ERD가 기업에는 중요하니
> 하이버네이트는 안된다"는 FUD가 계속 나타나겠지만요. 차라리 우리는 제대로된 ERD도 없고, 그때마다 주먹구구식으로 만들어서
> 테이블이 엉망진창이라 매핑할 엄두도 못내겠다라고 하면 차라리 이해가 갈텐데 말이죠.
>
> 2009/7/7 안영회 <ahnyoung...@gmail.com>
안영회
우리나라 개발자들을 결과를 빨리 얻기 원하는 것 같습니다.
쿼리 하나 날려서 원하는 결과를 얻고 이 결과를 기계적으로 화면 단에 전달에 표시하기를 원하는 거죠. Data가 구조화된 상태
로 관리되는 것은 DB로 충분하지 굳이 메모리에까지 구조화된 상태로 가지고 오기를, 그래서 그 자료를 다시 어떤 로직으로 처리하
기를 원하지 않는 것 같습니다.\
...
저는 이렇게 SQL에 대부분의 주요 로직이 들어가고 Java 코드는 단순히 인자를 전달하고 결과를 반환하는 일을 주로 하는 방
식의 개발 관행이 바뀌지 않는다면 ORM은 일할 양이 늘어나는 번거로운 기술로 받아들여질 듯 합니다.
결과를 빨리 얻기를 원하는 점은 개발자에 국한한 이야기는 아닌 듯 합니다.
그리고, 팀 단위 작업이라면 ERD는 아무 개발자에게나 맡기지 않잖아요.
ERD를 구성하는 어휘도 관리하고, 여력이 있는 경우 모델링과 검증을 위한 전문 인력을 두기도 하고
논리와 물리로 단계를 나누어 정규화도 하고, 이후에도 ERD에 입각해서 DB 객체를 만들어내고 관리하는 과정에 상당한 공수를 투입합니다.
즉, 중요하게 취급하죠.
하지만, ORM에 대해서도 그럴까요? ORM은 EA/ITA, SOA처럼 큰 돈을 보장하는 fancy한 기술이 아니기 때문에
지속적으로 노하우나 이점을 실제로 맛 보고, 이를 공유하고 가시화 되어지는 긴 과정이 필요한지 모릅니다.
어떤 면에서는 Spring이 주류로 올라선 과정을 ORM도 겪어야 하지 않나 싶고, 이미 그런 과정 중에 있는지도 모르죠.
Toby Lee
우병훈
Toby Lee
안영회
근데 X-Internet으로 데이터를 주고 받을 땐 꼭 flat 한 테이블 구조로 풀어서 엔티티정보를 담아야 하는 건가요? 1:n 구조를 유지하면서 (메인 폼+서브 그리드 같은) 주고 받을 순 없나요?
다수의 Dataset을 정의할 수 있으니 서버와 클라이언트 사이에서 1:N 형태로 송수시하는 일이 불가능하지는 않습니다.
다만, 수신하는 클라이언트쪽에서 의미상 참조 과계를 갖는 다수의 Dataset을 Compsite 형태의 객체로 변환하는 스크립팅 작업이 필요하겠죠.
안영회
Toby Lee
신승한
플렉스에서도 JSON 사용이 가능합니다.
리플렉션하는 메소드만 하나 만들어 놓으면 1:N:N 의 다중 중첩 구조나
여려 value Object와 Enum이 섞인 복잡한 객체라도
Hibernate에서 한번에 가져와서 간단하게 Flex로 전송 가능합니다.
Park, Sungchul
나의 iPod에서 보냄