PostgreSQL 놈의 장점 중에 하나가 배열 자료형을 사용할 수 있다는 것입니다. 물론 이것은 잘 알고 계시겠지요.

이 자료형은 간단한 Master-Detail 자료구조로 구현되는 두개의 테이블을 Master 자료형안에 그 Detail 부분을 배열로 처리해서 하나의 테이블로 자료를 담아 낼 수 있는 역활을 합니다.

물론 배열 자료형이 등장한 이유는 다각형과 같은 공간 개념 자료를 담기위해서이지만, 일반적으로 지리정보 시스템이나, 건축, 3D등 전문적인 디자인 관련 자료가 아니고서는 별로 쓸모가 없어보이는 자료형입니다.

하지만, 위에서 이야기했던 방식으로 사용된다면, 아주 유용하게 쓸 수 있는 자료형입니다.

예를 들어 한 사원이 여러가지 접근권한을 가져야할 경우,

T사원테이블
  F사원번호(PK)
  F사원이름

T사원접근권한테이블
  F사원번호(FK)
  F접근권한

이런방식으로 구현될 것을

T사원테이블
  F사원번호(PK)
  F사원이름
  F접근권한[]

이런방식의 배열로 사용된다면, 테이블 하나를 만들지 않아도 되고, 쿼리도 그만큰 간단해 지겠지요.

치명적인 단점이 있다면, 나중에 이 자료가 배열을 지원하지 않는 RDBMS로 옮겨간다면, 무진장 고생을 하겠지요.

여기까지가 서론이고,

배열 자료형을 접근하는 연산자나, 함수는 현재 PostgreSQL에서 디폴트로 제공하고 있지는 않습니다.

단지 source 안에 있는 contrib 디렉토리 안에서, array 모듈과 intarray 두 모듈을 부가적으로 제공하고 있습니다.

(개인적인 생각에는 PostgreSQL놈이 충실하게 ANSI SQL 구문을 지키려고 하는데, 이놈이 걸림돌이 되니까, 계속 contrib 디렉토리안에 두는 것이 아닐까하는 생각이 드네요)

array 모듈을 모든 배열 자료형을 지원합니다. 즉, int[] 뿐만 아니라, text[]까지도 지원하면서, text[] 자료형일 경우는 정규식까지 사용할 수 있어, 배열 자료형을 검색하는데 거의 불편함이 없도록 제공해 주고 있습니다.

문제는 이놈이 인덱싱을 전혀 지원하지 않는다는 것입니다.

즉, 쿼리를 만들어내는 이는 아주 꼼꼼하게 인덱싱 문제를 고려하지 않으면, 속도는 자료가 많으면 많을수록 검색 속도는 무지막지하게 증가합니다. (물론 이만큼 하드웨어를 빵빵하게 업그레이드하면 되겠지만)

한편, intarray 모듈을 촛점을 인덱싱에 맞추었습니다. 그리고, 사용할 수 있는 자료형으로는 int[]와, bigint[] 두개뿐입니다. 즉, 정수형 자료형에 대한 인덱싱 처리가 가능하도록 제공하고 있습니다.

이렇게 정수 배열형의 인덱스를 사용할 경우에는 이놈의 인덱스를 만들어 주어야하는데, 여기서 주의해야할 점은,

인덱스 파일의 형태를 gist라는 고유한 인덱스 형태를 꼭 지정해 주어야한다는 것입니다.

예:

CREATE TABLE a (a int[]);

CREATE INDEX a_a_i on a using gist (a);

현재 테스트해본 결과 *= 연산자(array 모듈에 있는 것)와, @@(intarray 모듈에 있고, 인덱스를 사용할 경우)연산자의 속도차이는 엄청난(!) 차이를 보였습니다.

개인적으로 배열 자료형을 사용하면서 끊임없이 찝찝했던 인덱싱 문제를 깔끔하게 해결해 주었습니다.

두 모듈의 설치와 사용법에 대한 자세한 설명은 각 모듈 디렉토리 안에 있는 README 파일을 참조하십시오.