정든 이글루스를 떠나 구글 Blogger 에 둥지를 틀었습니다.
떠나는 가장 큰 이유는 코드 넣는게 너무 힘들어서요^^
새로운 디밥의 블로그는 debop.blogspot.com 입니다.
거기서 뵙도록 하겠습니다.
- 2011/10/04 23:45
- debop.egloos.com/4138337
- 덧글수 : 2
일반적으로 각 RDBMS 마다 고유의 Client 가 있습니다만... 100% 마음에 드는 건 별로 없지요?
요즘 제가 MySQL을 쓰다보니 MySQL WorkBench 도 상당히 좋은 물건이긴 한데, Schema 정보 를 일괄로 본다던가 하는 기능이 부족하여, 불편함을 느끼다가, MySQL의 사촌격인 MariaDB를 설치하고, 알게 된 HeidiSQL 에 매료되어, 독자적으로 이용하고 잇습니다.
특히나 버전 6.0.0.3949 부터는 MS SQL Server 도 접근이 가능합니다. 현재까지는 이 두 DB밖에는 안되지만, 곧 PostgreSQL과 SQLite 등도 가능하지 않을까 조심스럽게 점쳐봅니다.
서버 Connection 등록 화면
MySQL DB의 모든 엔티티에 대한 정보를 목록으로 표현
더 많은 예는 HeidiSQL 홈페이지의 ScreenShot 에서 감상해 보세요.
쓸만한 공짜 툴이니 한번 써보세요^^
또 하나... MySQL용 Northwind DB 생성용 SQL Northwind-MySQL-db.sql 을 보너스로 드립니다. 스크립트 실행 속도를 감상해 보세요.
- 2011/10/03 23:12
- debop.egloos.com/4137823
- 덧글수 : 0
NHibernate 코드 매핑 이슈 에서도 나타냈듯이, 기존 FluentNHibernate 같은 경우는 HBM을 생성하고,
이를 NHibenate 엔진이 HBM을 Deserialize 해서 객체로 만든 후, 매핑을 수행하게 되어 있습니다.
NHIbernate 개발자 입장에서는 이러한 XML에 의한 매핑 방식에 API 에 의한 매핑 방식을 NH 3.2에 추가한 것이라 얘기하고 있습니다.
자 그럼, 좋은 점이 뭐냐? 아니 코드 매핑은 FluentNHibernate도 되므로, 코드 매핑의 장점 말고, 보다 좋은 점은 뭐냐?
핵심은 이 그림에 있습니다. (Fabio가 그린 그림입니다.)
즉 밑에 보이시는 모든 매핑 방식은 결국은 XML로 표현되고, 이를 deserialize하는 단계를 거치게 된다는 뜻입니다.
NH 3.2 의 Code Mapping API는 이러한 XML Deserialize 단계를 없애므로서, 초기 매핑관련 비용을 줄일 수 있다는 뜻이 되겠습니다.
장점은 이만하면 됐고, 그럼 예전부터 FluentNHibernate 을 사용했거나, 앞으로 사용할려고 하는데, 포기하고 NHibernate 3.2 Code Mapping 을 배워서 전환해야 하나요?
제 대답은 항상 같습니다. 다다익선이라고... 다 배워놓으면 좋지요 뭐... ㅎㅎ
자 그럼 결론부터 말씀드리자면, 무조건 초보는 HBM으로 공부하세요. 예제도 제일 많고, 공부할 때는 기초가 중요합니다.
두번째 Fluent NHibernate이냐 NH 3.2 Code Mapping API 냐는 미적 감각이나 코딩 습관에 따라 선택하세요.
자 첫번째 코드는 FluentNHibernate 로 Company 라는 엔티티를 매핑한 것입니다.
보시다시피 Fluent 방식 (Method Chain)을 잘 활용하여, 코드 읽기가 편합니다.
자 그럼 NH 3.2 Code Mapping 방식을 볼까요?
상당히 길죠? 같은 내용인데, Fluent 방식을 택하지 않고, Lambda Expression과 Anonymous Method로 표현하도록 했습니다.
뭐 코드가 길어질 뿐이지, 매핑하는데 HBM을 잘 안다면 공부할 필요가 없을 정도로, 유사합니다.^^
위의 두가지 방식 중에 선택하라고 한다면... 성능 위주라면, NH 3.2 방식을... 코드의 작성 및 가독성을 위한다면 FluentNHibernate 을 선택하겠습니다.
현재 FNH 도 1.3 for NH 3.2 를 준비중이고 (trunk 에서 다운받아서 사용하는데, 잘 됩니다) 앞으로도 계속 지원할 예정인 것 같으니, 배운다고 손해볼 건 없을 듯 합니다.
마지막으로... 가장 기본적인 HBM을 보시면... 위의 코드와 유사함을 아실 것입니다.
안그런가요? ㅎㅎ
이를 NHibenate 엔진이 HBM을 Deserialize 해서 객체로 만든 후, 매핑을 수행하게 되어 있습니다.
NHIbernate 개발자 입장에서는 이러한 XML에 의한 매핑 방식에 API 에 의한 매핑 방식을 NH 3.2에 추가한 것이라 얘기하고 있습니다.
자 그럼, 좋은 점이 뭐냐? 아니 코드 매핑은 FluentNHibernate도 되므로, 코드 매핑의 장점 말고, 보다 좋은 점은 뭐냐?
핵심은 이 그림에 있습니다. (Fabio가 그린 그림입니다.)
즉 밑에 보이시는 모든 매핑 방식은 결국은 XML로 표현되고, 이를 deserialize하는 단계를 거치게 된다는 뜻입니다.
NH 3.2 의 Code Mapping API는 이러한 XML Deserialize 단계를 없애므로서, 초기 매핑관련 비용을 줄일 수 있다는 뜻이 되겠습니다.
제 대답은 항상 같습니다. 다다익선이라고... 다 배워놓으면 좋지요 뭐... ㅎㅎ
자 그럼 결론부터 말씀드리자면, 무조건 초보는 HBM으로 공부하세요. 예제도 제일 많고, 공부할 때는 기초가 중요합니다.
두번째 Fluent NHibernate이냐 NH 3.2 Code Mapping API 냐는 미적 감각이나 코딩 습관에 따라 선택하세요.
자 첫번째 코드는 FluentNHibernate 로 Company 라는 엔티티를 매핑한 것입니다.
자 그럼 NH 3.2 Code Mapping 방식을 볼까요?
뭐 코드가 길어질 뿐이지, 매핑하는데 HBM을 잘 안다면 공부할 필요가 없을 정도로, 유사합니다.^^
위의 두가지 방식 중에 선택하라고 한다면... 성능 위주라면, NH 3.2 방식을... 코드의 작성 및 가독성을 위한다면 FluentNHibernate 을 선택하겠습니다.
현재 FNH 도 1.3 for NH 3.2 를 준비중이고 (trunk 에서 다운받아서 사용하는데, 잘 됩니다) 앞으로도 계속 지원할 예정인 것 같으니, 배운다고 손해볼 건 없을 듯 합니다.
마지막으로... 가장 기본적인 HBM을 보시면... 위의 코드와 유사함을 아실 것입니다.
안그런가요? ㅎㅎ
최근 덧글