아겔-_-의 뻘로깅

* object-relational impedence mismatch -- wikipedia
* Vietnam of Computer Science

많은 것들을 사용해보지는 않았지만 그간 허접하게나마 겪었던, 그리고 사용하는 Object-Relation Mapper들에 대해서 먼저 ㅆㅂ려봐야겠다.

* Hibernate (or JPA) : 자바. 클래스와 hbm.xml 파일, 혹은 annotation(이전에는 xdoclet)을 통해서 POJO의 매핑을 하는 방식. 다양한(아마도 현재 ORM이라면 이정도는 지원해야지.라는 정도의 범위) 매핑방식을 지원함. 예전에는 Criteria을 이용한 SQL이 아닌 방식으로 쿼리를 하는 방식을 지원했었고, JPA에서는 JPQL이라는 중립적인 SQL을 사용하여 쿼리를 하도록 해준다. 또한 객체들을 통한 Navigation도 당연히 지원한다. Magic등은 기대할 수 없지만, 매핑을 만드는데 있어서 추가적이거나 군더더기 없이 잘 표현할 수 있다고 생각됨.

* ActiveRecord : RubyOnRails의 기본 ORM. 기본적으로는 디비스키마를 이용하여 매핑 객체을 만들어낸다. 스키마가 존재하지 않더라도 migration등을 사용하여 스키마까지 만드는 방식을 지원. SQL을 사용하여 쿼리를 하거나 Object-Navigation을 이용하여 검색할 수 있다. 정말 필요한 부분만을 코딩하도록 하는 방식으로 매핑을 할 수 있다. 가장 객체지향적으로 자연스러운 방법으로 데이터에 접근할 수 있다고 생각한다. 하지만 많은 부분 매크로와 유사하게 module_eval등을 이용하고 있삼(나쁘다고 할수만은 없지만). 또한 루비의 특성으로 자연스럽게 플러그인을 추가하여 기능을 확장하기도 편리하다. 하지만 조금 복잡한 매핑이나 설정은 난감한 코딩이 필요함.

* SQLObject : 클래스 선언이라기보다 테이블 스키마를 파이썬 코드를 이용해 선언하고 이를 통해서 매핑을 지원한다. 추가적인 sqlbuilder 모듈을 통해서 중립적인 쿼리를 생성해낼 수 있도록 해준다. 역시 약간 복잡한 조인을 위한 설정이나 기타 설정들(디비연결이나 스키마...)등의 변수들이 magic-key와 연관이 있삼...

* SQLAlchemy : SQLObject와 매핑을 만드는 방식은 유사하나 기본개념에 차이가 있다. SQLObject은 위에서 다룬 Hibernate, ActiveRecord와 유사하게 매핑 객체가 하나만 존재하고 이를 통해서 바로 ORM을 구현하지만, SQLAlchemy은 RDBMS을 감싸는 모듈이 있고 그 위에 ORM 모듈을 구현한 형태. 기본적으로 한 테이블에 대해서 테이블 매핑 클래스와 OR 매핑 클래스가 존재해야함. Hibernate와 같이 다양한 매핑과 전략strategy을 지원하지만, 실제 구현에서 복잡함.


별로 이것들을 갖고서 뭔가 대단한 것을 만든것도 아니고 이들에 대해서 누구보다 빠삭하게 알고있는 것도 아니다.

거기에 문제는 한층 더해서 RDBMS에 대해서 그다지 잘알고 있지도 않다.

어느쪽이냐고 말한다면 RDBMS은 모르는데 그냥 그거 객체로 저장하고 객체에 대해서 navigation하는만큼만 되면 편리하겠다고 생각하는 사람이다.

솔직히 대부분의 ORM들이 객체설계에 추가적인 코딩을 필요로 하거나(당연하지만-_-), 심지어 객체의 설계에 제한을 두는 것이 사실이고, 이들의 navigation에 있어서 제약도 많고, SQL 인터페이스를 직접 사용하여 이들을 긁어오고 하는 것에 비해서 성능상에 문제도 많은 것이 사실이다. 캐슁이나 prefetch등 많은 바람직한 방법들로 이들을 보완하고는 있지만 솔직히 이들에 대한 세팅도 어떻게 본다면 추가적인 작업이고 specific한 작업이다.(물론 날로 먹겠다는 생각은 아니지만-_-;;)

정말로 현재 ORM을 사용하는 것이 ODBMS을 사용하는것보다 현실적이고 실용적인 대안일까?

1. 안정성 : 내 생각엔 안정적으로 디비가 깨지지 않는 것도 중요하지만 차라리 정책적으로 백업을 잘 마련하고 관리하는 것이 가장 현실적이라고 생각한다. (아무리 O디비를 쓰고 해도 언제 파일시스템이 날아가면 어떻게 할것인가? 디비의 안정성은 실제 존재하는 변수이지만, 어느정도의 안정성만을 갖추고 있다면 나머지 중요한 factor은 정책과 관리의 문제라고 생각한다.)
2. 속도 : 당연히 하나의 커다란 SQL문장을 따라오지는 못할거고, ORM이 어차피 다양한 캐슁과 prefetching등을 사용한다면 odbms은 더 유연하게 이들을 지원할 수 있지 않을까?
3. 생산성 : 대부분의 객체시스템이 일반화된 현재에 있어서 표준도 존재하고 복잡한 소프트웨어일수록 생산성이 증가한다고 생각된다.


떱. 그냥 진화의 중간단계에서 중얼거림.