얼마전부터 개인프로젝트용 DBMS로 SQLite를 사용하고 있습니다. 마땅한 GUI client를 찾아봤는데, 딱 마음에 드는건 없더군요. 그냥 Eclipse용 DB 플러그인으로 버티기로 하고 이것저것 물색하다가 다음과 같이 결론:

JDBC드라이버는 두 가지를 쉽게 구할 수 있습니다.

  • Christian Werner가 만든 Type 2 드라이버: http://www.ch-werner.de/javasqlite/
    • 구글에서 'sqlite jdbc'로 검색하면 제일 위에 올라옵니다.
    • Type 2이므로 DLL 설치 필요합니다.
    • 동작은 잘 되는데, SQL 문법에러 메시지 표시를 제대로 못해줍니다. (무조건 PreparedStatement 생성 예외로 나오더군요)
    • 접속 URL은 jdbc:sqlite:/c:/path/to/dbfile/sample.db 스타일. 드라이브명 앞에 '/' 들어갑니다.
  • David Crawshaw가 만든 Type 2 드라이버: http://www.zentus.com/sqlitejdbc/
    • 역시 Type 2이므로 DLL 설치 필요합니다.
    • 접속 URL은 jdbc:sqlite:c:/path/to/dbfile/sample.db 스타일입니다. 접속 URL이 틀릴 경우 'OutOfMemoryError'를 발생시켜 사람을 놀래키더군요.
    • SQL 문법에러 제대로 보여줍니다. 강추!
그런데 David Crawshaw의 JDBC 드라이버를 이용할 경우 QuantumDB에서 문제가 발생하더군요. (Sqlite는 특성상 catalog 개념이 없습니다. 파일 하나가 그냥 통째로 DB죠. 그래서 이 JDBC 드라이버에서는 DatabaseMetaData 쪽에서 catalog 관련한 부분을 null을 리턴하게 만들어져있는데, 이게 QuantumDB에서 문제가 되더군요 - 아래 화면처럼 트리가 망가지면서 NullPointerException 발생합니다)

QuantumDB

SQLExplorer


지금은 SQL Explorer를 테스트해보고 있는 중입니다. SQL 윈도우를 여러개 쓸 수 있어서 마음에 드는데, 한글문제는 잘 해결이 안되네요. 한글문제 해결하는 부분은 - 성공한다면 ^^ - 별도로 포스팅하겠습니다.


신고
  1. ErnestPr 2014.08.22 15:25 댓글주소 | 수정 | 삭제 | 댓글

    이용약관위배로 관리자 삭제된 댓글입니다.


한때 자바진영에서 설정(configuration)내용을 저장하는 포맷으로 .properties를 즐겨쓰던 시절이 있었습니다. 요새야 마음대로 확장가능한 포맷인 XML로 거의 다 넘어갔습니다만...

하지만 요새도 .properties를 사용하는 부분이 많이 남아있는데, 대표적인 것이 메시지리소스를 처리하는 부분입니다. 작년에 Struts를 이용해서 여러개의 언어를 동시에 지원하는 웹애플리케이션을 만들어야했던 적이 있습니다. 내부를 살펴보니, Struts 역시 PropertyResourceBundle을 이용해서 언어별로 별개의 .properties를 두게 돼있더군요.

가령 "안녕하세요"라는 메시지를 다음과 같이 각각의 .properties 파일에 넣어두면 나중에 "hello"라는 key를 넣었을때 현재 로케일에 맞는 메시지가 돌아오게 돼있는데요,
message_ko.properties:
hello = 안녕하세요
message_en.properties:
hello = Hello
message_ja.properties:
hello = はじめまして

그런데, 저렇게 생긴 .properties 파일을 그대로 사용하면 한글이나 일본어는 제대로 나오지 않습니다. .properties 파일이 공식적으로 ISO-8859-1밖에 지원하지 않거든요. 따라서 ant의 native2ascii 등을 이용해서 다음과 같은 형태로 .properties 파일을 변환해주어야 합니다.
message_ko.properties:
hello = \uc548\ub155\ud558\uc138\uc694
message_en.properties:
hello = Hello
message_ja.properties:
hello = \u306f\u3058\u3081\u307e\u3057\u3066
보시다시피 표준 US-ASCII 코드페이지 바깥에 존재하는 문자들은 앞쪽에 \u가 붙은 unicode escape형태로 저장되게 됩니다. 조금 귀찮지만 선택의 여지가 없었기 때문에, .properties 파일 변경되면 매번 native2ascii 실행시켜줬었죠.

그런데 올해 들어 다시 저 프로젝트를 잠깐 손봐줄 일이 생겼는데, 매번 native2ascii 실행시켜주려니까 너무 귀찮더군요. 그사이에 뭐가 획기적인 방법이 나오지 않았을까 싶어 검색해봤더니, 일본 개발자들이 이미 Properties Editor라는 프로그램을 만들었두었더군요. stand-alone 애플리케이션 버전도 있고, Eclipse나 JBuilder 플러그인 버전도 있습니다.

Eclipse 버전만 써봤는데, 에디터 화면에서 글자를 입력하면 저장하는 시점에 자기가 알아서 unicode escape 형태로 저장해줍니다.

[Properties Editor]

[실제 파일내용]

뷰와 모델을 분리함으로써 얻을 수 있는 이익을 극대화한 사례라고나 할까요? 어쨌든 이 프로그램을 사용하게 되면서 native2ascii는 이제 역사의 뒤안길로 사라졌답니다. ^^
신고
  1. 별이 2007.05.17 10:45 신고 댓글주소 | 수정 | 삭제 | 댓글

    좋은정보 감사 해요!!

  2. Favicon of http://hkjinlee.tistory.com BlogIcon 진이헌규 2007.05.17 13:19 신고 댓글주소 | 수정 | 삭제 | 댓글

    별이 / 도움이 되셨다니 기쁩니다. 만드신 분들이 대단하신 분들이지요 ^^





티스토리 툴바