안녕하세요? 예전부터 빠르고 안정적으로 운영되는 DSN을 보고 postgresql에 관심을 가져오다가 얼마전부터 테스트를 시작한 사용자 입니다.

현재 mysql 5.0을 가지고 작읍 웹개발 프로젝트를 진행중인데 처리양이나 동시사용등 보다는 data의 무결성이 상당히 중요한 프로젝트이다 보니 mysql 에서 제공하는 낮은수준의 consistant로는 한계와 염증을 느끼고 있는중입니다 (sql_mode부분에서 경악을 해버렸습니다 OTL) 그래서 다음 버전이나 다다음 버전 정도 postgresql 을 이용해서 개발을 해볼 생각이 있는데 가장 큰 걸림돌은 지금 현재 프로젝트에서 mysql 의 enum 과 set 자료형 의 비중이 상당히 크다는 점입니다.

물론 enum 같은경우 text column에 check 제약조건, set의 경우 bit string type으로 메칭 시킬수 있겠지만 각각 한계가 존재합니다.

구체적으로 예를 들자면 enum 타입의 경우 check 제약조건을 사용해서 저장하면 enum 과 동일하게 저장은 할수 있지만 mysql enum 처럼 enum index를 통한 처리 (enum('a','b','c')의 컬럼의 경우 a->1,b->2,c->3 의 enum index 에 각각 메칭되어 insert , select 시에 enum index를 통한 질의가 가능합니다 ) 가 불가능 합니다. 둘째 set 자료형 -> bit string type 의 경우는 상태를 bit string에 저장할수 있겠지만 '상태의 내용'은 유실되기 때문에 별도 참조 테이블을 만들던가 application logic쪽에서 참조 정보를 가져야 하는 문제가 발생합니다 (이는 enum을 bit string으로 처리했을때도 동일합니다 )

개인적으로 mysql 의 enum 과 set 자료형이 올바른 DB 설계나 데이터 모델링에 부합하지 않는 면은 있겠지만 실용적인 측면에서는 상당히 유용한 형태ㅤㄹㅢㅤ data type이라고 생각합니다 (특히 web 개발 환경에서 enum 과 set 자료형은 radio와 check box input object 와 완벅하게 match가 됩니다)  ( 아울러 mysql 에서 set 자료형의 활용에 대해서는 http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html 이 문서에 잘 소개가 되어있습니다 )

오늘 벼르고 벼르던 FreeBSD 서버에 postgresql 8.2.4를 설치하고 (이것때문에 커널껌파일까지;;;) 공식 document를 거의 다 독파하며 조금씩 테스트를 해봤는데 하면 할수록 더이상 mysql을 사용할 이유가 전혀 없다는 확신이 들고 있는데 마지막으로 걸리는문제가 이 두 자료형에 대한 문제입니다.

비슷한 형태의 질문이 이전에 올라와있는것은 봤는데 단순한 1차적인 답변밖에 없어 혹시 저랑 비슷한 고민을 하셔서 답을 찾은 분이 계신지 해서 이렇게 질문 남겨봅니다. 얼마전 8.2.4 릴리즈 뉴스에 덧글을 보니 8.3에서는 enum data type이 지원이 될 예정이라고 하던데 8.3에서 지원되는 enum type이 mysql의 그것과 비슷하게 동작(enum index 측면에서) 하는지도 궁금합니다.

감사합니다.

ps. 질문을 올리고 생각이 나서 구글링을 해보니 8.3에 추가될 enum data type에 대한 문서가 벌써 나와있더군요 !! http://developer.postgresql.org/pgdocs/postgres/datatype-enum.html#AEN5348 (질좋은 공식문서 역시 postgresql의 큰 매력인것 같습니다) 살펴보니 일단 컨셉은 일반적인 enum과 동일한것 같고 (저장은 bit로 하고 해당 bit에 대한 참조테이블을 가지고 있는 형태의 data type) ordering 부분을 봤을때 index를 통한 연산도 가능한것으로 보이는데 ( >, < 같은 연산자가 동작한 부분을 봤을때) 혹시 8.3을 직접 사용중이신분 계시다면 확인부탁드리겠습니다!!

ps2. 그리고 postgresql enum 으로 구글링해서 나올 결과의 top page 문서들은 대부분 ㅤㅎㅜㅀ어봤는데 제가 원하는 답은 없는것 같습니다 그나마 가장 근접한 접근이 oreily에 올라와있는 http://www.oreillynet.com/pub/a/databases/2006/01/06/enumerated-fields-in-postgresql.html 인데 여기서 제시하는 2번째 해결방법 ( enum filed에 대한 참조 테이블을 생성하고 foreign key 제약조건을 사용) 같은 경우 가장 교과서 적이고 모델링상으로도 깔끔한 해결책이 될수 있겠지만 문제는 현재 프로젝트에서 enum 으로 정의된 컬럼이 줄잡아 200개는 넘는 상황이라서 (boolean type으로 대체할수 있는 'YES','NO' 를 제외하더라도 100개이상) 이모든 케이스에 대해 참조테이블을 생성하고 관리하는것은 현실적으로 어려움이 있어보입니다.

ps3. 점점 자문 자답화 되어가고 있습니다만 ;; 저에겐 꽤 흥미로운 주제라 이시간까지 계속 자료를 찾아보고 있습니다 @_@ mailling list 를 뒤져보니 enums patch 라는 patch 와 함께 enum type에 대한 논의가 있었던 모양입니다 http://archives.postgresql.org/pgsql-patches/2006-12/msg00099.php , http://archives.postgresql.org/pgsql-patches/2006-12/msg00114.php 특히 두번째 스레드는 enum 타입의 불필요성에 대해 지적한 내용에 대한 반박으로 enum patch의 제작자가

Well, there are a number of cases where ordering IS important, and indeed, enums provide a way to do it easily where many of the alternative solutions do not. It's one of the key benefits.

확인결과 PGXS 관련해서 뭔가 문제가 있어서 compile이 진행이 되지 않는것 같습니다 (PGXS가 뭔지 전혀 몰라서 진행을 못하고 있습니다) 아울러 enum type에 대한 design 과 proposal 을 정리한 스레드도 있었는데 http://archives.postgresql.org/pgsql-hackers/2006-08/msg00979.php 메일링리스트를 계속 구독한게 아니라 오늘 검색으로 찾아낸것들이라 어떤식으로 논의가 진행되었는지는 잘 모르겠습니다. 점점 질문인지 잡담인지 정체를 알수 없는 글입니다 ;;