그루비 에서 스칼라 로

[박제권]

요즘 스칼라쪽 책을 보고는 있는데, 잘 찾기 힘든 부분이 있어서.. 질문올려봅니다.

아래는 디비 마이그레이션하는 (한쪽디비를 변형해서, 다른 디비에 저장하는 단순한) 코드인데요.

def set = sql_to.dataSet('t_members')

sql_from.eachRow("select * from old_table order by id asc") { rs ->
println rs.ms_name

def map =[ m_id :rs.ms_id,
m_name : rs.ms_name,
m_nick : somef(rs.ms_nick),
...]
set.add(map);
}

대략 이런 코드였습니다. 여기에서 eachRow 나, add(map) 부분이 꽤 마음에 들었었습니다.

이 코드를 스칼라로 옮겨보려고 시도해봤는데..
오렐리책 13장 DSL설명하는 부분에서 SQL관련 설명이 약간 나오는것 말고는
책에서는 잘 다루지 않는 주제인 것 같습니다.

전에 우리그룹에서도 언급된것 같은..
http://lpsherrill.blogspot.com/2009/07/using-scala-with-groovysqlsql.html
는 있습니다만. 올바른 해법인지 궁금합니다.

차라리 저 링크에서 Daniel Spiewak 이 남긴 코멘트가 더 관심이 갑니다만, 제대로된 코드는
아닌것같군요. 어쩌면 스칼라에서는 그냥 JDBC를 이용해도 편리하더라... 일지도 모르겠다는
생각도 드네요..

이 분야에 경험이 있는 분 계시면, 어떤식으로 시작하셨는지 조언 부탁드립니다~~.

[drypot]

다른 것도 그렇겠지만 디비 기술 선택은 개인의 작업 스타일에 따라서 많이 달라지는 것 같습니다.

외주를 받아서 3 개월이나 6 개월 안에 완료하고 납품하는 경우
큰 문제 없는 쓰기 편한 아무 기술이나 선택하고 프로젝트를 완료하면 될 겁니다.
JDBC 든, 하이버네이트든, iBatis 든 상관이 없이
클라이언트가 원하든지, 팀이 익숙한 기술이면 될 것 같습니다.

그런데 본인이 직접 10 년 이상 관리하고 생명을 유지해야하는 프로젝트이면 얘기가 좀 달라집니다.
경험상 많은 유틸리티 기술들은 생명이 짧지 않습니까.
신 세상이 온 것 처럼 마케팅 하던 것들도 그냥 속절없이 사라지곤 합니다.

디비 유틸리티 기술 뿐만이 아니고,
10 년 이면 운영체제가 몇 번 바뀌고, 중간 플랫폼이 바뀌고, 언어도 바뀌고,
대응해야하는 클라이언트도 바뀌고, 여튼 모든 것들이 바뀝니다.

디비 유틸리티 기술만 놓고 보더라고 자주 업데이트가 나오기 때문에
그 추세를 따라가려 하다보면 사실 프로젝트 어플리케이션 내용을 보강하는 것 보다
배꼽이 더 커지는 상황이 왕왕 발생합니다.

M$ 에서 C#, F# 왔다갔다 하면서도 느꼈고,
자바로 이사와서 Groovy, Scala 이사 다니면서도 느꼈지만,
비표준이나 살짝 사용하기 편한 기술들이 유혹이 강하지만
멀리 보고 냉정하게 판단하면 이놈들이 운신의 폭을 매우 제한한다는 것을 알 수 있습니다.
Linq 도 그랬고, GrooySql 도 그랬던 것 같습니다.
아주 편리하지만 다른 언어로 이사가는데 걸림돌이 됩니다.
하이버네이트나 iBatis 도 그런 면에서 결코 자유롭지 못한 것 같습니다.
기술이란 것이 개선도 중요하지만 구 버전 호환성과 기반의 생명이 긴 것도 중요한 것 같습니다.

요즘 다시 스프링하고 EJB 저울질 하느라 아직 본격적으로 스칼라 코딩에 들어가진 못했는데,
저 같은 경우는 디비 유틸리티 편의성을 포기하고 언어 이사 다시는 것에 촛점을 맞추어
걍 JDBC 쓰는 쪽으로 많이 기울어지고 있습니다.

근간 삽질들을 통해 전 디비 유틸리티 기술보다 언어에 더 관심이 있어서
다른 언어로 이사가는데 걸림돌이 되는 것은 가능한 줄여야 한다는 것을 깨달았습니다.
그래서 DSL 류는 최대한 피하고, ORM 이나 iBatis 는 써도 될 것 같긴 한데 그 마저도 신경 쓰지말고,
걍 JDBC 를 써서 DAO 들 만들어 두면 자바 안 에서는
같은 코드를 앞으로 10 년간 계속 이사 시키는데 큰 문제가 없을 것 같다는 생각입니다.

덧: 필명을 바까봤습니다. ^^

On Jan 30, 1:10 pm, 박제권 <jayp...@gmail.com> wrote:
> 요즘 스칼라쪽 책을 보고는 있는데, 잘 찾기 힘든 부분이 있어서.. 질문올려봅니다.
>
> 아래는 디비 마이그레이션하는 (한쪽디비를 변형해서, 다른 디비에 저장하는 단순한) 코드인데요.
>
> def set = sql_to.dataSet('t_members')
>
> sql_from.eachRow("select * from old_table order by id asc") { rs ->
> println rs.ms_name
>
> def map =[ m_id :rs.ms_id,
> m_name : rs.ms_name,
> m_nick : somef(rs.ms_nick),
> ...]
> set.add(map);
>
> }
>
> 대략 이런 코드였습니다. 여기에서 eachRow 나, add(map) 부분이 꽤 마음에 들었었습니다.
>
> 이 코드를 스칼라로 옮겨보려고 시도해봤는데..
> 오렐리책 13장 DSL설명하는 부분에서 SQL관련 설명이 약간 나오는것 말고는
> 책에서는 잘 다루지 않는 주제인 것 같습니다.
>

> 전에 우리그룹에서도 언급된것 같은..http://lpsherrill.blogspot.com/2009/07/using-scala-with-groovysqlsql....

[Jay Park]

답변 감사드립니다.

> 디비 유틸리티 기술만 놓고 보더라고 자주 업데이트가 나오기 때문에
> 그 추세를 따라가려 하다보면 사실 프로젝트 어플리케이션 내용을 보강하는 것 보다
> 배꼽이 더 커지는 상황이 왕왕 발생합니다.

이 부분이 특히 도움이 되었습니다~. ^^

---------------
http://groovy.pe.kr/30
http://jinto.pe.kr

2010년 1월 30일 오후 10:31, drypot <dry...@gmail.com>님의 말:

--
"한국 Groovy & Grails 사용자 그룹" 에 가입하셨기에 이 메시지를 보내드립니다
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
KG...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
KGGUG+un...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/KGGUG?hl=ko의 그룹을
방문하세요.

[drypot]

Scala 디비 관련 도우미가 Grails GORM 처럼 Lift 에 Lift Mapper 라고 들어있군요.
아직 구체적인 작동방법이 이해된 것은 아닌데,
특이한 점은 어노테이션이 아닌 스칼라 문법으로 데이터 형식을 기술한다는 겁니다.

Lift Mapper 에서는 이것이 빛을 발하는 부분이 validation 인데요,
필드를 정의하는 곳에 스칼라 문법으로 기본값이나 validation 을 꾸며 놓을 수가 있습니다.
이런 데서 어노테이션 안 쓰니 깔끔해 지는군요.
일단 이미 아는 문법으로 정의를 할 수 있으니.

자바나 Groovy 에서도 필드별로 클래스를 만들면
어노테이션 없이 유연하게 처리가 가능할텐데 하는 생각이 듭니다.

validation 을 각 페이지에서 안 하고 한 모델 클래스에 몰아면 장점이 있듯이,
validation 을 각 모델 클래스에서 하지 않고 각 필드 클래스에 돌아두니 더 좋아지네요.

Java EE 6 스펙에서도 일반 펑션 콜로 처리해야할 것을
과도하게 어노테이션으로 처리하는 경우가 보였는데,
어노테이션이 도입되고 나서 이쪽으로 너무 무리하게 가는거 아닌가 싶습니다.

그러나, 결국 이런식 접근을 하면 SQL 이 사라져서, =,=
시퀄 콜하는 것이 어마나 잘 되어있는지는 더 봐야 겠습니다.

일단은 모델 기술하는 것은 하이버네이트나 GORM 보다 Lift 방식이 좋아보이네요.

On Jan 31, 2:43 am, Jay Park <jayp...@gmail.com> wrote:
> 답변 감사드립니다.
>
> > 디비 유틸리티 기술만 놓고 보더라고 자주 업데이트가 나오기 때문에
> > 그 추세를 따라가려 하다보면 사실 프로젝트 어플리케이션 내용을 보강하는 것 보다
> > 배꼽이 더 커지는 상황이 왕왕 발생합니다.
>
> 이 부분이 특히 도움이 되었습니다~. ^^
>

> ---------------http://groovy.pe.kr/30http://jinto.pe.kr

> > KGGUG+un...@googlegroups.com <KGGUG%2Bunsu...@googlegroups.com>
> > 추가 옵션을 보려면http://groups.google.com/group/KGGUG?hl=ko의그룹을
> > 방문하세요.

[백기선]

M$ 에서 C#, F# 왔다갔다 하면서도 느꼈고,
자바로 이사와서 Groovy, Scala 이사 다니면서도 느꼈지만,
비표준이나 살짝 사용하기 편한 기술들이 유혹이 강하지만
멀리 보고 냉정하게 판단하면 이놈들이 운신의 폭을 매우 제한한다는 것을 알 수 있습니다.
Linq 도 그랬고, GrooySql 도 그랬던 것 같습니다.
아주 편리하지만 다른 언어로 이사가는데 걸림돌이 됩니다.
하이버네이트나 iBatis 도 그런 면에서 결코 자유롭지 못한 것 같습니다.
기술이란 것이 개선도 중요하지만 구 버전 호환성과 기반의 생명이 긴 것도 중요한 것 같습니다.

조금더 구체적으로 어떻게 운신의 폭이 매우 제한되는지 궁금합니다.

시간이 지나고 새로운 언어가 나온다고 해서 이미 구현되어 있는 시스템을 구현한 언어나 프레임워크까지 바꿔야 하는 경우가 생기는건가요??

2010년 1월 30일 오후 10:31, drypot <dry...@gmail.com>님의 말:

다른 것도 그렇겠지만 디비 기술 선택은 개인의 작업 스타일에 따라서 많이 달라지는 것 같습니다.

--
"한국 Groovy & Grails 사용자 그룹" 에 가입하셨기에 이 메시지를 보내드립니다
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
KG...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
KGGUG+un...@googlegroups.com

추가 옵션을 보려면 http://groups.google.com/group/KGGUG?hl=ko의 그룹을
방문하세요.

--
좋은 하루 되세요~

[Sewon Ann]

drypot 님이 말씀하신 것과 기선님의 질문은 약간 다른 측면이 아닐까 생각합니다.

drypot 님의 말씀은 언어를 변경하고자 할 경우 비표준이나 살짝 사용하기 편한 기술들이 이러한 언어 변경을 힘들게 만드는 요인이라는 내용으로 이해가 되네요. sql 을 직접 박아넣은 경우 그대로 휙 copy& paste 해서 갖다 옮길 수 있지만, hibernate 같은 경우 힘드니까요.
기선님의 질문과 같이 새 언어가 나온다고 레거시 시스템을 갈아엎어야 한다는 내용은 아니라고 이해하였습니다.

그러나 drypot님의 관점을 거꾸로 생각해보면, 매번 sql 에 의존하는 경우라면 새 언어나 시스템으로 옮겨타는 이득이 적으니 결국 "왜 새 언어로 가야하지?" 하는 부분에 대해서 다시 의문점이 드네요. 물론 biz. logic 을 개선하는데 새 시스템이 훨씬 좋다면 설득력이 있겠지만요. ORM을 못쓰고 계속 sql 에 집착한다면 구닥다리 java 프레임웍에서 새로나온 scala 프레임웍으로 옮기는 메릿이 확 줄어드는게 아닐까 하는 생각이에요. (DB측면에 국한하여 생각하는 경우.)

안세원 드림.

2010/2/8 백기선 <whites...@gmail.com>

[백기선]

아;;;;

아주 편리하지만 다른 언어로 이사가는데 걸림돌이 됩니다.

다른 언어로 이사를 가려고 할 때 저런게 문제라는 것이군요;; 그렇다면;; 다시..

"언어를 바꿀 것을 고려하여" 웹 애플리케이션을 개발 중인데 DAO 단을 SQL과 JDBC로 코딩을 할까 하이버네이트(이녀석도 SQL을 직접 쓸 수 있죠.)로 할까 고민인데.. 언어를 스칼라로 바꿀지도 모르니까 스칼라에서도 재사용할 수 있는 SQL만 쓰자...

이런건가요??

그럼 SQL 이 외의 나머지 코드는 어찌되나요. 커넥션 만들고 열고 닫고 리절트셋이며 스테이트먼트며;; 얘네 조작하던 코드들 어차피 다 갈아타야 할텐데.. 저는 그럴바엔 어차피 하이버네이트를 쓰나마나 대동소이한 변경이라고 느껴지거든요;;

그래서 다시 질문드립니다.

어떤 운신의 폭이 제약이 되는건가요?

2010년 2월 8일 오후 5:28, Sewon Ann <kin...@gmail.com>님의 말:

--
좋은 하루 되세요~

[김성배]

언뜻 생각난 예를 하나 든다면 C/S환경의 Power Builder 프로그램을 웹기반 자바로 바꾸는 경우가 있지 않을까요.
시대에 따라서 호스트기반이 C/S환경으로 바뀌고 C/S환경이 웹기반으로 바뀌고 합니다.
웹 이후의 뭔가를 상상하기는 힘들지만 다른게 있다면 그 기반에 따라 언어도 바뀌는 경우는 충분히 있을것 같습니다.
얼마전까지도 C/S기반의 프로그램을 웹기반으로 바꾸는 프로젝트가 참 많았던거 같은데
이런 경우 사실 가져다 쓸것은 SQL밖에 없기도 합니다.

2010/2/8 Sewon Ann <kin...@gmail.com>:

[drypot]

제가 말했던 "아주 편리하지만 다른 언어로 이사가는데 걸림돌이 됩니다." 라는 부분은
언어에 종속적인 데이터베이스 처리를 이야기했던 것인데,
아시겠지만 기술마다 언어 의존의 정도가 다릅니다.

가장 심한 것은 제일 편리한 DSL 류이고요.
Java 쪽에서는 딱히 예를들만큼 유명한 놈이 없는 것 같은데,
예를 들면 C# 의 LINQ 나 F# 의 DSL 같은 것들입니다.

아래 예는 C# 코드인데 from, join, orderby 같은 것이 아예 C# 키워드로 들어와 있는 형태입니다.
하이버네이트라면 HSQL 로 기런걸 기술하던 것 같은데, C# 에서는 컴파일러가 지원을 합니다.

from search in PostSearch(categoryID, query)
join header in PostThreads on search.ThreadID equals header.ThreadID
orderby header.UDate descending

F# 이나 Scala 같은 펑셔널 언어에서는 DSL 기능이 좋아서 컴파일러가 지원하지 않아도
아래와 같은 구문을 만들어 쓸 수 있습니다. 아래 예는 F# 코드입니다.

let expensiveInStockProducts =
products
|> where (fun p -> p.UnitsInStock > 0 && p.UnitPrice >
Convert.ToDecimal(3.00))
|> select (fun p -> p.ProductName);;

이런 DSL 류나 HSQL 류는 쓰기는 편한데,
언어를 바꾸거나 프레임웍을 바꾸려할 때 손을 대기 어려운 점이 있습니다.

하이버네이트 같은 경우 언어에서 조금 거리가 있으므로,
조금은 쓰기 불편하지만 조금은 유연성을 가지는 그런 위치가 될 것 같습니다.

같은 언어, 프레임웍을 쓰더라도 프레임웍의 정책이 바뀌면 난감해 질 수 있습니다.
M$ 환경에서 아주 좋은 예가 있었는데 첨에 LINQ 나오면서 마케팅을 열심히 해서
모두 열심히 공부하고 준비했는데,
Entity Framework 어나운스 되면서 아직 나오지도 않은 EF 때문에
LINQ 업그레이드가 중지될 꺼란 소문이 파다했습니다.
나중에 M$ 에서 진화에 나서긴 했지만
지금 사용하는 프레임웍이 언제까지 쓸 수 있을지는 알 수가 없습니다.

알 수 없는 미래 때문에 당장 쓰기 편한 것을 아예 쓰지 말자는 쪽은 아니고요,
프로젝트 정책을 결정할 때 이 것이 독인지 아닌지를 장기적인 관점에서
더 세심히 고민해야한다는 정도로 봐주시면 될 것 같습니다.
물론 이런 고민을 할 때 프로젝트의 성격이나 생명주기같은 것에 따라
판단은 천차만별일 겁니다.

위 내용과는 별도로 저는 ORM 에 대해 부정적인 면을 많이 보는 편입니다.
SQL 은 Java 와 같은 저급언어에 비해 매우 고급언어 입니다.
고급 언어가 하는 일을 저급 언어로 기술하려하면 구문이 복잡해질 수 밖에 없습니다.
SQL 이 하는 일은 가능한 SQL 이 하도록 넘기는 것이 구문이 간단해집니다.

Java 에서 SQL 사용이 어려워 지는 것은 Java 의 스트링 처리 기능이 떨여져서,
Java 와 SQL 의 인터페이스가 지저분해 진다는 것인데,
이것만 편하게 해주면 큰 문제는 안 생깁니다.

ORM 은 이 인터페이스 문제를 클래스와 테이블의 매핑을 기반으로 해결하려 드는데,
전에도 한번 적었지만 여기서 모든 재난이 시작됩니다.
RDB 테이블은 클래스와 1:1 대응이 아닙니다.
이걸 억지로 끼워 맞추기 위해 ORM 의 클래스 정의가 한도 끝도 없이 복잡해집니다.
게다가 대부분의 ORM 들은 SQL 구문의 기능을 자꾸 하려고 듭니다.
그것도 한참 저급 언어로.
그러니 공부할 것만 늘어나고 문제 해결은 잘 안 되고, 프로젝트는 계속 복잡해집니다.

건강보험 처럼 ORM 이 없어도 별 문제가 아닐 것 같은 상황에서는 ORM 이 깔끔하게 잘 작동합니다.
근데 조금만 문제가 복잡해 지면 ORM 자체 문제가 불거지기 때문에 골치아픈 상황들이 생깁니다.
이때가 SQL 의 필요성이 들어나는 순간인데, 이걸 또 HSQL 같은 걸로 막으려 듭니다.
HSQL 설명서 보면 소소한 장점이 있습니다.
근데 그런 소소한 장점으로 원론을 바꾸긴 어려워 보입니다.

말이 너무 길어졌습니다. ^^

그래서, 당신이 생각하는 지금 답은 뭡니까 물어보시면,
사실 잘 모르겠습니다. ^^

최근에 본 것 중에는 GroovySQL 이 제일 성공적인 글루 기술이었던 것 같습니다.
스칼라에도 GString 같은 것이 들어갔으면 좋겠는데,
개발진으로 부터 퇴짜를 맞았습니다.

웹 프레임웍도 그렇고, 뷰 엔진들도 그렇고, ORM 도 그렇고,
너무 자기 분수를 넘어서 과도해지는 것 같습니다.
그래서 문제를 해결해 주는 것 뿐만 아니고, 다른 문제들을 너무 많이 야기합니다.

실무에서 그 어떤 경우에도 테이블의 모든 컬럼을 통체로 가져오는 경우는 거의 없습니다.
한 테이블만 쓰는 경우도 거의 없구요.
SQL 결과는 항상 릴레이션으로 정리가 되어 오고 OO 에서 처럼 그래프가 아닙니다.
그걸 좀 인정해 줬으면 좋겠습니다.
무리하게 OO 식 그래프로 데이터를 바꾸지 말고.
Java 가 SQL 을 그대로 인정하고 인터페이싱에만 집중해도 매우 다른 기술이 나올겁니다.

On Feb 8, 6:54 pm, 김성배 <sungbae....@gmail.com> wrote:
> 언뜻 생각난 예를 하나 든다면 C/S환경의 Power Builder 프로그램을 웹기반 자바로 바꾸는 경우가 있지 않을까요.
> 시대에 따라서 호스트기반이 C/S환경으로 바뀌고 C/S환경이 웹기반으로 바뀌고 합니다.
> 웹 이후의 뭔가를 상상하기는 힘들지만 다른게 있다면 그 기반에 따라 언어도 바뀌는 경우는 충분히 있을것 같습니다.
> 얼마전까지도 C/S기반의 프로그램을 웹기반으로 바꾸는 프로젝트가 참 많았던거 같은데
> 이런 경우 사실 가져다 쓸것은 SQL밖에 없기도 합니다.
>

> 2010/2/8 Sewon Ann <king...@gmail.com>:

>
> > drypot 님이 말씀하신 것과 기선님의 질문은 약간 다른 측면이 아닐까 생각합니다.
>
> > drypot 님의 말씀은 언어를 변경하고자 할 경우 비표준이나 살짝 사용하기 편한 기술들이 이러한 언어 변경을 힘들게 만드는 요인이라는
> > 내용으로 이해가 되네요. sql 을 직접 박아넣은 경우 그대로 휙 copy& paste 해서 갖다 옮길 수 있지만, hibernate
> > 같은 경우 힘드니까요.
> > 기선님의 질문과 같이 새 언어가 나온다고 레거시 시스템을 갈아엎어야 한다는 내용은 아니라고 이해하였습니다.
>
> > 그러나 drypot님의 관점을 거꾸로 생각해보면, 매번 sql 에 의존하는 경우라면 새 언어나 시스템으로 옮겨타는 이득이 적으니 결국
> > "왜 새 언어로 가야하지?" 하는 부분에 대해서 다시 의문점이 드네요. 물론 biz. logic 을 개선하는데 새 시스템이 훨씬 좋다면
> > 설득력이 있겠지만요. ORM을 못쓰고 계속 sql 에 집착한다면 구닥다리 java 프레임웍에서 새로나온 scala 프레임웍으로 옮기는
> > 메릿이 확 줄어드는게 아닐까 하는 생각이에요. (DB측면에 국한하여 생각하는 경우.)
>
> > 안세원 드림.
>

> > 2010/2/8 백기선 <whiteship2...@gmail.com>

[백기선]

drystop님께서 생각하시는 ORM은 굉장히 어처구니가 없는 녀석이로군요.. 저급 언어로 고급 언어인 SQL이 하는 것을 하려 들다니.. 문제만 복잡하게 만들구 말이죠.. 흠;;

저는 하이버네이트가 SQL과 대립되는 기술이라고 생각하지를 않아서.. 저랑은 생각이 많이 다르신것 같네요. 흠;;

나머지 LINQ, F#, GroobySQL, GString은 공부 해본적이 없어서 잘 모르겠네요;;

근데 DSL은 혹시 Domain Specific Language의 약자아닌가요? 이건 특정 언어에 국한 된 기술이 아니라 internal DSL, external DSL등 약간 개념적인 단어 같은에 F#의 기능 처럼 적으셨네요. 그 DSL이 아닌가요;;

2010년 2월 8일 오후 9:16, drypot <dry...@gmail.com>님의 말:

--
좋은 하루 되세요~

[Sanghyuk Jung]

음 drypot님의 의견은 저하고는 생각이 좀 다르신 것 같은데요,

 

SQL이나 Java나 고급이나 저급의 수준(기계에 가까우냐 인간에 가까우냐의 문제죠)의 수준은 비슷하다고 느껴집니다. SQL도 성능최적화를 위해서 어떻게 조인이 되고, index를 어떻게 타게하게하고, 어떻게 파티셔닝을 하고 고민하다보면 기계에 가까운 영역이 많습니다. SQL이 특별히 추상화의 수준이 더 높은 것도 아니라고 느껴집니다. 다만 두 언어가 해결하는 문제의 영역이 다른데, 잘 아시다시피 데이터 집합을 기술하는 영역과 절차적 처리를 포함한 보다 넓은  모든 영역을 다루는 언어의 차이라고 생각됩니다. 그리고 제가 봤던 레거시 시스템의 대부분의 문제는 SQL이 그 영역을 벗어나서 너무 많을 일을 해서 모든 로직이 SQL에 들어가 있고 5~6개 테이블 조인한 한페이지가 넘어가는 SQL들로 다른 사람이 이해하기 힘든 코드들을 양산해 내는 것들이 아니었나하구요.

 

 ORM이 적어도 그런 SQL의 남용사례를 어느 정도 막는 제약은 가할 수 있지 않나하는 점에서 전 ORM에 대해서 긍정적인 편입니다. 그리고 객체 중심의 사고 방식이 캐쉬적용, DB 종류 변경이나 심지어 RDB를 벗어난 저장소(Big table류도 될 수 있겠죠)에도 범용적으로 쓰일 수 있는 접근방식이라는 장점도 생각할 수 있고요. 프레임웍이나 언어를 옮기는 정도를 대비할 정도로 미래를 생각한다면, DB 종류를  변경하거나 RDB라는 것 기술 자체도 영원하지 않다는 가정을 하는 것이 너무 앞서나가는 가정은 아니라고 생각합니다.

 

 그리고, 모든 컬럼을 다 쓰는 화면은 없겠지만, 성능에 다소 손해가 있더라도 모든 컬럼을 다 가지고 오는 메소드를 하나 만들고 그 메소드를 여러 곳에서 호출하는 것이 재활용성이 높은 접근이고, 그것이 일반적인 컴퍼넌트 설계에서 coarse grained한 접근방식과도 일맥상통하는 것이 아닌가하구요.

 

 RDB를 기준으로 생각한다면, ORM이 억지로 RDB를 객체에 끼워맞추는 것 같겠지만, 반대로 객체중심으로 생각한다면 RDB 객체가 영속화되어서 저장될 수 있는 저장소의 일종일 뿐이라고 생각할 수도 있습니다. RDB만으로 개발해오신 분들에게는 억지같은 이야기라고 생각하실 줄 몰라도, 이미 Object를 global 캐쉬 같은 곳에 저장을 한다던지 하는, 기존 RDB를 벗어난 저장소 전략을 추가로 적용을 하지 않는다면 scalability를 감당할 수 없게 되는, 포탈 같은 쪽에서는 바로 당면한 문제라고 느껴집니다. application의 중심을 어디에 두느냐의 문제라고 생각됩니다.

 

 

> 실무에서 그 어떤 경우에도 테이블의 모든 컬럼을 통체로 가져오는 경우는 거의 없습니다.
> 한 테이블만 쓰는 경우도 거의 없구요.
> SQL 결과는 항상 릴레이션으로 정리가 되어 오고 OO 에서 처럼 그래프가 아닙니다.
> 그걸 좀 인정해 줬으면 좋겠습니다

 

 위에서 말씀하신 방식도 선택가능한 접근방식 중의 일부라고 생각합니다. 즉 SQL을 어떻게 쓰느냐의 문제입니다. 저도 옛날에 SQL처음 배울 때는 성능을 위해서 꼭 필요한 컬럼만 가지고 오라고 배웠는데, 몇년전부터는 모든 컬럼을 다 select하는 방식을 대부분 쓰고 있습니다. 그렇지 않으면 매화면마다 거의 1개씩의 SQL이 나오는데, 아주 성능에 민감한 부분이 아니라면 그렇게 모든 경우의 SQL을 다 짜주는 것이 생산성을 저해한다고 생각됩니다. 그리고 SQL이 한테이블만을 조회하는 경우가 없다는 것은 그만큼 '한방쿼리'를 만들기 위해 더많은 종류의 SQL이 만들어지고, 긴 SQL이 만들어진다는 것인데, 이것도 결국 화면1개에 1개의 SQL이 나올 가능성이 높습니다. 여러개로 잘라서 SQL을 날린다면 그 만큼의 그 쿼리가 재사용성이 높아질 수도 있고, 코드의 가동성도 높아지겠죠. 물론 여러번의 쿼리가 성능에는 안 좋을 수도 있습니다. 그런데 Application의 모든 부분이 그 만큼의 성능부담도 허용되지 않는 상황은 거의 없습니다. 그리고 구글에서는 BigTable류를 저장소로 이용해서 조인없이 내부 업무시스템을 만들었다는 이야기도 들었습니다.

 

2010년 2월 8일 오후 11:13, 백기선 <whites...@gmail.com>님의 말:

[신승한]

HIbernate의 덕을 크게 보고 있는 입장에서 보니  HIbernate같은 ORM이 유독 안티가 많은거 같네요.

그래도 개발자 입장에서 칼퇴근을 도와주는 도구는 Spring도 Groovy도 아닌 Hibernate인거 같습니다.


한국 SI에서 항상 문제가 되는건 ORM으로 생성된 SQL의 성능이 아니라.

미숙한 개발자가 손으로 작성한 장문의 또는 중복된 SQL이더군요.

2010년 2월 9일 오전 12:11, Sanghyuk Jung <ben...@gmail.com>님의 말:

[drypot]

말씀들 잘 들었습니다.

글쓰기 라는 것이 제한이 많다 보니 한쪽에 치우친 내용을 중심으로 적었었는데,
말씀해 주신 내용들에 대해 저도 동의하는 바가 많고
ORM 에 부정적인 생각을 하면서도 적어주신 내용들과 비슷한 생각이 또 한쪽 구석에 같이 있습니다.

저는 좀 옛날 사람이라 8KB, 16KB 제한에서 프로그래밍을 시작해서,
요즘 기계들의 대역을 믿고 판단을 내리는데 아직도 많이 주저합니다.
코딩을 할 때 괜한 걱정을 많이해서 로직을 구축하는데,
막상 서비스를 올리고 나면 사용자가 제일 몰리는 시간에도 CPU 를 10% 밖에 사용 안 하고 있고,
스페어로 같이 주문한 기계들은 팽팽이 놀리는 사태를 자주 만들곤 했습니다. =,=

SQL 에 대해서는 스토어드 프로시저를 정석으로 생각하던 시대 사람입니다. ^^
SQL 로직을 어플리케이션 서버에 박는 요즘 모습을 보고 꽤 놀랬어서,
이런 문화에 적응하는데 적지 않은 시간을 쏟았었습니다.

요즘은 ORM 과 웹 뷰 엔진들의 과도한 계층화를 만나서는
다시 또 마음속에 계속 충돌이 발생하고 있습니다.

그런데, 이런 과정들이 재미가 있습니다.
가지고 있던 생각들 계속 부서져 나가는게 홀가분 하기도 하구요.
먼가 또 다른 꿍꿍이를 가진 사람들의 아이디어 보는 것이 항상 흥미진진하구요.
그렇습니다. ^^

On Feb 9, 8:55 am, 신승한 <my.p...@gmail.com> wrote:
> HIbernate의 덕을 크게 보고 있는 입장에서 보니 HIbernate같은 ORM이 유독 안티가 많은거 같네요.
>
> 그래도 개발자 입장에서 칼퇴근을 도와주는 도구는 Spring도 Groovy도 아닌 Hibernate인거 같습니다.
>
> 한국 SI에서 항상 문제가 되는건 ORM으로 생성된 SQL의 성능이 아니라.
>
> 미숙한 개발자가 손으로 작성한 장문의 또는 중복된 SQL이더군요.
>

> 2010년 2월 9일 오전 12:11, Sanghyuk Jung <bene...@gmail.com>님의 말:

> > 2010년 2월 8일 오후 11:13, 백기선 <whiteship2...@gmail.com>님의 말:

> ...
>
> read more >>

[Jay Park]

엉뚱한 말씀입니다만,
이 쓰레드의 시작이 제 메일이었군요.
갑자기 영광스럽다는 생각이.. ㅎㅎ

---------------
http://groovy.pe.kr/30
http://jinto.pe.kr

2010년 2월 9일 오전 8:55, 신승한 <my....@gmail.com>님의 말:

[박성철]

>
> 엉뚱한 말씀입니다만,
> 이 쓰레드의 시작이 제 메일이었군요.
> 갑자기 영광스럽다는 생각이.. ㅎㅎ
>

축하드립니다. ㅎㅎ
좋은 토론이네요.

[Myoungsoo Shin]

아 재미있는 토론이 벌어지고 있었군요. +_+
좀 관계가 있는 듯 한 블로그 포스트가 있어서 남깁니다.
http://codemonkeyism.com/orms/

[김성배]

Groovy & Grails 메일링 리스트로 시작했으나
drypot님의 언어,프레임웍 기행기 메일링 리스트로 변경된것 같습니다.
(메일링 리스트 활동이 저조하여서지만..)
개인적으로는 요새 어떤 블로그보다도 재밌게 보고 있습니다~

그냥 요즘 유행하는 다수가 쓰는 프레임웍, 라이브러리를 별 의문없이 받아들이고 사용하다가 drypot님의 글을 보면서 다시
뒤돌아볼수 있는 계기가 되는 것 같습니다.

회사에서 거의대부분 Java로 개발하지만 어쩌다 php프로젝트가 생겨서 작업하고 있는데 언어 자체는 별로 재미없지만 무엇인가를
수정하면 0.1초면 볼수 있는 반응성이 좋군요. 10년 전에 봤던 php도 아니고 rails스타일의 프레임웍도 있네요.
모든것이 장단점이 있습니다.

drypot님이 어디에 안착하실지 매우 궁금합니다~

2010/2/9 drypot <dry...@gmail.com>:

[박성철]

> 아 재미있는 토론이 벌어지고 있었군요. +_+
> 좀 관계가 있는 듯 한 블로그 포스트가 있어서 남깁니다.
> http://codemonkeyism.com/orms/
>

영어잖아요! 요약해주세요. ㅎㅎㅎ

대충 봤는데 요즘 생각하던 것과 비슷한 내용도 있네요.
결국 SQL과 RDBMS가 쇠퇴하면 ORM 기술도 의미 없어진다는...

물론 급격한 변화는 아니더라도 Clouding Computing이 탄력을 받고 있는 상황
에 무시할 내용은 아닌 듯 합니다.