database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Columns 4586 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 4586
MySQL에서 PostgreSQL로 옮길 때 알아야 할 것들.
작성자
김상기(ioseph)
작성일
2003-02-18 03:14
조회수
15,819

http://techdocs.postgresql.org/techdocs/mysql2postgresql.php

 

언제가 제가 한 번 써야지 했던 글이 윗글에 있었군요.

주위에서 "왜 빠른 MySQL을 포기하고, PostgreSQL로 바꾸어야하는가?"에 대한 이야기를 많이 듣습니다.

 

그때마다 저는 아주 오래전 이야기를 꺼집어냅니다.

쓰기편했던 M$동네를 떠나서 까만색화면에 흰글자밖에 없었던 리눅스라는 놈으로 옮겨갔던 그 시절의 이야기를.

(물론 지금은 제가 리눅서라고 불리기를 강력히 거부하고, 또 누구도 저더러 리눅서라고도 안하지만 -.-)

 

전혀 연관성이 없는 이야기 같지만, 저에게 있었어는 MySQL에서 PostgreSQL로 옮겨간 이야기는 리눅스를 시작하던 때와 비슷합니다.

도데체 OS라는 놈이 뭘까? 왜 사람들은 리눅스에 관심을 가질까? 이것처럼

도데체 SQL이라는 놈이 뭘까? 왜 사람들은 빠른 MySQL 나누고 PostgreSQL 이야기를 그것도 Oracle도 아닌 많이 사용하지도 않는 그 낯선 RDBMS를...

 

윗 영어 문서 모두를 그대로 옮겨두면 좋겠지만, 귀찮아서...

아무튼 글의 요지는 제가 말하고 싶었던 것과 크게 다르지 않습니다.

 

PostgreSQL은 비교적 충실히 SQL 표준 규약이라고 하는 ANSI SQL을 지킵니다. 또한 지금까지 제가 보아 왔던 PostgreSQL 놈은 그렇게 해왔습니다. Oracle의 그 편한 outer join도 포기(?)하고, ANSI 구문을 따르며, case when, null 과 empty stirng 의 관계, limit, offset 구문, string concat 구문..

 

또한, RDBMS의 특징인 "관계" 문제에 있어서도 MySQL과 비교도 안될 정도의 많은 기능이 있습니다. (그 "관계"를 속도 때문에 무시했던 MySQL도 요즘은 많이 관심을 가지더군요)

 

또한 DB 설계 및 구현과 응용 프로그램을 함께 개발하는 사람들의 공통된 생각 - 제가 알고 대부분 사람들의 생각입니다, 물론 제가 알지 못하고 있는 더 많은 사람들의 생각은 어떨지는 모르겠지만 -

"DB에서 할 수 있는 모든 일은 DB에서 하고 응용 프로그램으로 넘겨주라!" 이 관점에서도 PostgreSQL놈은 그 몫을 톡톡히 해냅니다. - 물론 Oracle하고 비교하면 비교도 안될 정도로 미약한 수준이지만 -

 

----

여기까지 그 영문의 요지이고,

 

제가 마음에 들어하는 것 중에 하나가,

PostgreSQL은 MySQL보다 눈에 보이는 것이 초라하다는 것.

어느 기업의 대대적인 지원을 받고 있는 것도 아니고,

거대한 사용자 층을 가지고 있는 것도 아니여서,

문제가 발생 되었을 때, 즉각 대처하지도 않고,

카리스마 넘치는 리더가 있어, 새로운 사용자를 쉽게 만들지도 못하는,

마치 위태위태하는 프로젝트처럼 움직입니다.

 

하지만!!!

그렇기 때문에,

표준이 아니다 싶으면 과감하게 표준으로 바꿉니다.

설계/구현 단계에 있어 기본 이론적 바탕이 충실합니다.

(다들 서로 자신만의 표준을 만들어가고 있는 시점에,

PostgreSQL놈은 자신의 것을 내세우기 보다는 ANSI SQL 구문이

이러니까 우리도 이렇게 간다...는 식입니다)

또한 순수한 오픈소스로 운영될 가능성이 다른 것들보다 큽니다.

또한 새로운 구현에 대한 도입이 빠릅니다.

 

이렇게 이야기 하니까 꼭 약장사 같은데,

사용자나 개발자가 중급자 이상의 어느정도 SQL 구문을 마음대로 만지는 경지에 도달하면 PostgreSQL 놈은 그 자신의 은근한(?) 매력을 보여줍니다. :)

이 글에 대한 댓글이 총 4건 있습니다.

음...postgreSQL은 RDBMS는 아니죠.

ORDBMS가 맞지 않나요?

 

빠른 MySQL을 사용하지 않고 ORDBMS로 넘어가는 이유는

RDBMS가 가진 한계 때문이라고 생각합니다.

관계형 테이블로는 디자인하기 힘든(굳이 한다면 할수 있지만...) 것들이 있기 때문이라고 봅니다.(예를 들어 지도관련 데이타들, 멀티미디어 데이터들...)

 

오라클(8i 부터인가?)이나 MSSQL 현재 ORDBMS형태입니다.

MySQL은 ORDBMS가 될수 없다고 보여집니다.

 

그렇다고 MySQL에서 postgreSQL로 가야하나?

그건 아니라고 생각합니다.

적재 적소에 알맞은 DBMS. 저는 이렇게 생각합니다.

-_-a님이 2003-03-03 11:36에 작성한 댓글입니다.

빠른 MySQL을 사용하지 않고 ORDBMS로 넘어가는 이유는

 

-> 빠른 MySQL을 사용하지 않고 postgreSQL로 넘어가는 이유는

 

정정합니다.

그리고 MSSQL은 현재 ORDBMS 형태인지 확실치 않습니다만 그럴꺼 같습니다. :-)

-_-a님이 2003-03-03 11:40에 작성한 댓글입니다.

은근한 매력 <- 참 와닿네요 -.-;;

 

pgsql을 쓰고나서는 mysql은 단순검색 또는 게시판용으로나 적합하다고 나름대로 판단을 내렸는데..

요즘은 그것도 아니라는 생각이 듭니다 -_-;

이젠 어떤 프로젝트도 다 pgsql을 쓰고 있습니다 -_-;

지금 회사에서 모든 프로젝트에서 mysql을 철수시킨다는 단기적 계획을 세우고 그렇게 가고 있습니다 =_=

ORDBMS, 충실한 표준 준수 만이 아니더라도 이눔의 은근한 매력을 나열하기가 귀찮을 정도입니다 -_-;;;

 

개인적인 희망으로는 pgsql이 SQL3 표준을 100% 지원하는 최초의 DBMS가 되었으면 좋겠습니다 -.-

신기배(nonun)님이 2003-03-25 17:55에 작성한 댓글입니다.

엄밀히 따지자면 MYSQL 역시 RDBMS 라 할 수 없지 않을 까요.

 

MY SQL은

"관계" 부분을 포기한 M$의 Access 정도의 시스템이라고 밖에는 생각되지 않더군요. ANSI표준의 많은 부분을 지키지 않고, 그 기능 역시 구현 되어 있지 않지요.

 

실제 MY SQL로 작업을 해보면, DB에서 지원하지 않는 기능 때문에 결국 그 만큼을 프로그램에서 해야 하지요.

 

그럼 속도라는 것도 DB가 프로그램으로 전가 시켜버리기 때문에 얻는 거 밖에 되지 않는게 아닐까요.

 

쩝... 두서 없이 몇 자 적어 봅니다.

고한하님이 2003-04-10 23:08에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
5139tsearch2 한국어 파서 사전 개발안 [8]
김상기
2004-01-04
16056
4939DSN 개발 뒷 이야기 [4]
김상기
2003-09-13
11980
4860PostgreSQL을 얼마나 오래 사용하고 있나요?
김상기
2003-08-24
11801
4586MySQL에서 PostgreSQL로 옮길 때 알아야 할 것들. [4]
김상기
2003-02-18
15819
4341Why You Need Database Normalization
정재익
2002-09-13
13773
4297PostgreSQL: Taking E-Business Up a Notch
정재익
2002-08-14
23273
4270Partial Indexes
정재익
2002-07-26
10598
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.050초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다