|
0. 데이터베이스의 인코딩에 따라서 사용할 수 있는 문자가 아주
엄격합니다.
한국사람 입장에서 본다면, 이 부분이 제일 민감한 부분
같습니다.
아무생각없이, euc-kr 문자셋 기반으로 데이터베이스를 만들었다면,
PostgreSQL 에서는 '햏'이나, '쓯' 같은 글자를 입력할 수가 없습니다.
원척적으로 막혀있습니다. 왜냐하면, 이들 글자는 euc-kr 문자가 아니기
때문입니다.
그래서, 한국어의 모든 글자를 아무 문제 없이 사용하려면,
데이터베이스 인코딩으로 사용할 문자셋은 utf-8(unicode)
여야합니다.
클라이언트가 이런 utf-8 기반이 아니라면,
set client_encoding to uhc;
같은 명령으로 사용하고 있는 클라이언트 인코딩 항상 먼저 지정해
주어야합니다.
자세한 이야기는
http://database.sarang.net/?inc=read&aid=5129&criteria=pgsql
페이지 문서를 참고하세요.
1. 자료형이 비교적 엄격합니다.
varchar(20) 이렇게 컬럼을 정의했다면, 글자단위(byte 단위가 아닌,
글자 단위입니다.)로 딱 20 글자만 입력할 수 있습니다. 입력이 이보다
크다면, 오류를 냅니다.
몇몇 기종은 이렇게 정의하고, 큰 값이 오면 자동으로 알아서 잘라서
입력해주지요. 하지만, 이런 작업을 아에 하지 않습니다.
또, 자료형 자체가 엄격한 자료형일 경우는 그것에 충실합니다. 그
대표적인 것이, date, time, timestamp 형입니다. 이 자료형을
사용하겠다고 정의해 두고는 그 컬럼에 '2005-02-29' 같은 날짜를
입력하면, 자동으로 '2005-03-01' 로 입력되는 것이아니라, 오류를
냅니다. 이것은 time 자료형도 마찬가지입니다.
또, 가장 짜증내는 부분이, null 자료와 empty string('') 자료를
엄격하게 구분합니다.
그래서, 정수형 자료형에서는 '' 표현을 사용할 수 없습니다.
빈문자열('')은 숫자가 아닌 문자열이기 때문입니다. 또한 null 자료에
대한 검색은 = 연산자를 사용할 수 없습니다. 반드시 is null, 또는 is
not null 형태로 사용됩니다.
2. 컬럼 별명에는 반드시 as 예약어를 사용해야합니다.
select a from t; (o)
select a as name from t; (o)
select a name from t; (x)
3. 인덱스, 시퀀스, outer join, 몇몇 함수 등 꽤 많은 부분은 ANSI
SQL 구문을 따릅니다. 그래서 이런 부분들에 대해서 해당 RDBMS 고유
표현 방식으로 되어 있는 부분은 모두 바꾸어야합니다.
outer join의 예제 설명 문서
http://database.sarang.net/?inc=read&aid=5765&criteria=pgsql
nvl() 함수는 coalesce() 함수로,
decode() 함수는 case when 구문으로,
left(), right() 함수 등은 substr() 함수로
4. 대용량 데이터가 copy 명령을 통해서 한꺼번에 자료가
입력되었다면, 쿼리 옵티마이져의 바른 동작을 위해서, 자료 통계 수집
작업은 한번 수동으로 해 주어야합니다.
vacuum analyze;
또는
vacuum analyze table_name;
5. 아직 통계수집기와, 쿼리 옵티마이져가 미흡해서, 숫자 자료형의
>, < 비교 연산에 대한 인덱스 사용은 주의를 기우려야합니다.
물론 대부분의 경우에서는 자료통계가 일반적으로나마 있다면, 이런
경우에 신경을 안써도 되겠지만, 자료가 수십만건이 넘어가는
경우에서는 꼭 explain 명령으로 옵티마이져의 선택을 확인해
보셔야합니다.
안전한 방법은 일단 범위를 지정하는 것입니다.
select * from account where no > 100; (권장하지 않음)
select * from account where no between 100 and 200; (이런식으로
사용되면 안전합니다)
6. 서버 관리 차원에서 부득이한 경우가 아니라면, 서버 프로세스를
kill -9 명령으로 종료하지 않아야합니다. 7.1 버전부터 이런
비정상적인 종료에 대비한 안전한 자료관리를 하고 있다고는 하나, -
또한 지금까지 사고로 인해 자료를 손실했는 경우는 없었으나 -
PostgreSQL 동네 쪽에서는 부득이한 경우가 아니라면, 절대로 KILL(9)
시그널은 보내지마라고 이야기합니다.
7. 현재 시간을 구하는 now() 함수는 하나의 트랜잭션 안에서
트랜잭션 시작 시간만을 리턴합니다.
이 이야기는 트랜잭션을 사용하는 환경에서는 아주 중요한
이야기입니다. plpgsql 구문도 일종의 트랜잭션임으로 plpgsql
구문안에서 사용되는 now() 함수의 결과도 마찬가지 결과를 나타냅니다.
이와 같은 처리는 버그가 아니라, 일종의 정책입니다. 개인적으로
보아도 하나의 트랜잭션에서의 "현재시간"은 그 트랜잭션안에서
동일해야한다고 생각됩니다.
--------------
글을 쓰고 나니, 온통 안된다는 이야기들 뿐이군요. :)
개인적인 견해는, PostgreSQL 쪽을 사용하다보면,
이런 엄격함에도 불구하고, 잃는 것 보다 얻는 것이 더
많습니다.
|
