그루비 에서 스칼라 로
박제권
아래는 디비 마이그레이션하는 (한쪽디비를 변형해서, 다른 디비에 저장하는 단순한) 코드인데요.
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
--
"한국 Groovy & Grails 사용자 그룹" 에 가입하셨기에 이 메시지를 보내드립니다
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
KG...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
KGGUG+un...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/KGGUG?hl=ko의 그룹을
방문하세요.
drypot
아직 구체적인 작동방법이 이해된 것은 아닌데,
특이한 점은 어노테이션이 아닌 스칼라 문법으로 데이터 형식을 기술한다는 겁니다.
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 도 그런 면에서 결코 자유롭지 못한 것 같습니다.
기술이란 것이 개선도 중요하지만 구 버전 호환성과 기반의 생명이 긴 것도 중요한 것 같습니다.
조금더 구체적으로 어떻게 운신의 폭이 매우 제한되는지 궁금합니다.
시간이 지나고 새로운 언어가 나온다고 해서 이미 구현되어 있는 시스템을 구현한 언어나 프레임워크까지 바꿔야 하는 경우가 생기는건가요??
다른 것도 그렇겠지만 디비 기술 선택은 개인의 작업 스타일에 따라서 많이 달라지는 것 같습니다.
--
"한국 Groovy & Grails 사용자 그룹" 에 가입하셨기에 이 메시지를 보내드립니다
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
KG...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
KGGUG+un...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/KGGUG?hl=ko의 그룹을
방문하세요.
--
좋은 하루 되세요~
Sewon Ann
drypot 님의 말씀은 언어를 변경하고자 할 경우 비표준이나 살짝 사용하기 편한 기술들이 이러한 언어 변경을 힘들게 만드는 요인이라는 내용으로 이해가 되네요. sql 을 직접 박아넣은 경우 그대로 휙 copy& paste 해서 갖다 옮길 수 있지만, hibernate 같은 경우 힘드니까요.
기선님의 질문과 같이 새 언어가 나온다고 레거시 시스템을 갈아엎어야 한다는 내용은 아니라고 이해하였습니다.
그러나 drypot님의 관점을 거꾸로 생각해보면, 매번 sql 에 의존하는 경우라면 새 언어나 시스템으로 옮겨타는 이득이 적으니 결국 "왜 새 언어로 가야하지?" 하는 부분에 대해서 다시 의문점이 드네요. 물론 biz. logic 을 개선하는데 새 시스템이 훨씬 좋다면 설득력이 있겠지만요. ORM을 못쓰고 계속 sql 에 집착한다면 구닥다리 java 프레임웍에서 새로나온 scala 프레임웍으로 옮기는 메릿이 확 줄어드는게 아닐까 하는 생각이에요. (DB측면에 국한하여 생각하는 경우.)
안세원 드림.
백기선
아주 편리하지만 다른 언어로 이사가는데 걸림돌이 됩니다.
"언어를 바꿀 것을 고려하여" 웹 애플리케이션을 개발 중인데 DAO 단을 SQL과 JDBC로 코딩을 할까 하이버네이트(이녀석도 SQL을 직접 쓸 수 있죠.)로 할까 고민인데.. 언어를 스칼라로 바꿀지도 모르니까 스칼라에서도 재사용할 수 있는 SQL만 쓰자...
이런건가요??
그럼 SQL 이 외의 나머지 코드는 어찌되나요. 커넥션 만들고 열고 닫고 리절트셋이며 스테이트먼트며;; 얘네 조작하던 코드들 어차피 다 갈아타야 할텐데.. 저는 그럴바엔 어차피 하이버네이트를 쓰나마나 대동소이한 변경이라고 느껴지거든요;;
그래서 다시 질문드립니다.
어떤 운신의 폭이 제약이 되는건가요?
--
좋은 하루 되세요~
김성배
시대에 따라서 호스트기반이 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>
백기선
저는 하이버네이트가 SQL과 대립되는 기술이라고 생각하지를 않아서.. 저랑은 생각이 많이 다르신것 같네요. 흠;;
나머지 LINQ, F#, GroobySQL, GString은 공부 해본적이 없어서 잘 모르겠네요;;
근데 DSL은 혹시 Domain Specific Language의 약자아닌가요? 이건 특정 언어에 국한 된 기술이 아니라 internal DSL, external DSL등 약간 개념적인 단어 같은에 F#의 기능 처럼 적으셨네요. 그 DSL이 아닌가요;;
--
좋은 하루 되세요~
Sanghyuk Jung
> 한 테이블만 쓰는 경우도 거의 없구요.
> SQL 결과는 항상 릴레이션으로 정리가 되어 오고 OO 에서 처럼 그래프가 아닙니다.
> 그걸 좀 인정해 줬으면 좋겠습니다
신승한
HIbernate의 덕을 크게 보고 있는 입장에서 보니 HIbernate같은 ORM이 유독 안티가 많은거 같네요.
그래도 개발자 입장에서 칼퇴근을 도와주는 도구는 Spring도 Groovy도 아닌 Hibernate인거 같습니다.
한국 SI에서 항상 문제가 되는건 ORM으로 생성된 SQL의 성능이 아니라.
미숙한 개발자가 손으로 작성한 장문의 또는 중복된 SQL이더군요.
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
박성철
>
> 엉뚱한 말씀입니다만,
> 이 쓰레드의 시작이 제 메일이었군요.
> 갑자기 영광스럽다는 생각이.. ㅎㅎ
>
좋은 토론이네요.
Myoungsoo Shin
김성배
drypot님의 언어,프레임웍 기행기 메일링 리스트로 변경된것 같습니다.
(메일링 리스트 활동이 저조하여서지만..)
개인적으로는 요새 어떤 블로그보다도 재밌게 보고 있습니다~
그냥 요즘 유행하는 다수가 쓰는 프레임웍, 라이브러리를 별 의문없이 받아들이고 사용하다가 drypot님의 글을 보면서 다시
뒤돌아볼수 있는 계기가 되는 것 같습니다.
회사에서 거의대부분 Java로 개발하지만 어쩌다 php프로젝트가 생겨서 작업하고 있는데 언어 자체는 별로 재미없지만 무엇인가를
수정하면 0.1초면 볼수 있는 반응성이 좋군요. 10년 전에 봤던 php도 아니고 rails스타일의 프레임웍도 있네요.
모든것이 장단점이 있습니다.
drypot님이 어디에 안착하실지 매우 궁금합니다~
2010/2/9 drypot <dry...@gmail.com>:
박성철
대충 봤는데 요즘 생각하던 것과 비슷한 내용도 있네요.
결국 SQL과 RDBMS가 쇠퇴하면 ORM 기술도 의미 없어진다는...
물론 급격한 변화는 아니더라도 Clouding Computing이 탄력을 받고 있는 상황
에 무시할 내용은 아닌 듯 합니다.