매뉴얼에서 schema 로 찾아보면, schema에 대한 설명이 있습니다. schema를 쓰는 몇가지 이유를 들어놓기도 했네요. 해석해드리면 좋겠지만 직접 보시면, 더 이해가 잘되시리라 생각됩니다.

감사합니다.

문서 1레벨 목차에는 information schema 만 있어서 못찾앗는데

ddl부분에 설명이 있네요.

There are several reasons why one might want to use schemas:

•To allow many users to use one database without interfering with each other.

•To organize database objects into logical groups to make them more manageable.

•Third-party applications can be put into separate schemas so they do not collide with the names of other objects.

오라클하고는 권한주는 체계가 조금 틀린듯해서 테스트를 더 해봐야겟지만

예전 방식으로 public 만 사용하는것이 혼자쓸때는 가장 깔끔하네요.

위질문의 배경에는 고객은 유지보수를 위해 같은 사용자를 원했고

컨설팅업체는 어플리케이션별로 권한을 주고 싶은듯 한데

업무레벨까지 권한관리를 하려는 듯 약간 오버를 한듯합니다.

(실 데이터 담당자는 논리적으로 나누어도 3개정도면 충분하다고 하네요)

아무튼 잘 이야기로 풀어 봐야 할듯 합니다.

synonym 사용을 단지 코딩을 편하게 하기 위한 table alias 로만 사용한다면,

단지 view로 충분히 대체 가능할 것입니다.

접근 권한 문제도 충분히 view로 가능할 것 같고,

이런 문제들로 성능상에 문제가 발생하지는 않을 것 같습니다.

제가 그외 synonym의 다른 용도를 잘 몰라서,

그 외부업체의 컨설팅이 제가 보기에는 더 타당성이 있어보입니다.

자료관리측면과 서버효율성 문제를 보아도 필요하다면 네임스페이스 분리하는 것이 더 타당하겠죠.

한 예로, public 안에 10만개의 다른 테이블이 존재하고,

그 가운데 하나의 테이블을 select 하려고 할 때의 비용과,

그 10만개 테이블을 10개의 스키마안에 분리해서 보관하고,

그 하나의 테이블을 select 하려고 할 때의 비용은 당연히 후자가 나을 것 같습니다.

서버는 분명  pg_class 카타로그 자료를 모두 메모리에 올려놓고 운영되지 않을 것이고,

그렇다면, 쿼리분석기는 일단 그 테이블의 고유ID를 찾기 위해서 pg_class 테이블을 참조할 것이고,

그 참조할 때의 비용은 당연히 후자가 적게 들 것 같네요.

(안해봐서 모릅니다 - 글 쓰면서 열심히 머리를 굴려보니, 제 생각이 틀릴지도 모르겠다는 생각도 들기도 합니다.)

영문

http://www.postgresql.org/docs/8.4/static/ddl-schemas.html

한글

http://www.postgresplus.co.kr/man/ddl-schemas.html

여기는 테이블이 전체적으로 4~50개도 안돼고

관리는 최대한 한곳에서 하도록 고객은 요구하고 권한도 필요없고 하니

이곳에서는 전체를 public으로 가거나 (권장하지 않으니)

이식성을 위해서 유저와 동일한 스키마 하나에서 모든것을 하는게 가장 올바른 답이겠네요.