A 회원사가 B 회원사의 어떠한 자료도 접근하지 않아야하지 않나요?

그러면 당연히, A회원사용 DB 따로 B회원사용 DB 따로 ... 이렇게 움직여야할 터인데,

공통으로 새로운 view 하나를 만들어 공통적으로 적용해야한다면, 관리 측면에서 고생이 심할 것같네요.

오라클 쪽의 개념을 도입하면, 한 회원사는 하나의 DB 용 계정을 사용하고, 하나의 독립된 테이블스페이스를 사용하는 식이 일반적인 설계입니다.

즉, 시스템 카타로그 계열쪽은 모든 회원사가 공유하는게지요.

이 방법을 PostgreSQL 쪽으로 생각하면, 하나의 데이터베이스에 여러개의 스키마를 만들고, 각 스키마의 소유주를 각각 회원사 DB 계정으로, 그 자료공간은 각각의 테이블스페이스로 잡는 것이 일반적이겠지요.

이렇게 하면, 공용 테이블을 함께 쓸 수 있어 좋거든요. 예를들어서 우편번호 같은 테이블.

문제는 A 회원사가 백업과 정기 점검 차원에서 DB 서버를 혹사 시키고 있다면, B 회원사 쪽에 영향을 미치는 것은 당연할 것이고 이 부분은 같은 시스템 안에 있다면, 아에 DB cluster 자체를 따로 만들어 관리한다고 해도 안고 가야할 문제같네요.

제가 생각하기에는 그렇게 문제가 발생하면, 피해를 입는 회원사 쪽에서 "우리 회사 DB 따로 꾸릴터이니, 메인터넌스 해 달라"고 요청하겠지요. :)

마치 웹 호스팅 하다가 서버 호스팅 하는 것처럼 :)

이야기의 요지는 하나의 DB에 여러개의 스키마를 두는 것이 좋을 듯싶습니다.

참, 아주 중요한 이야기를 빼먹었네요.

PostgreSQL의 시스템 카타로그는 각 DB별로 관리 됩니다. 예를들어서 pg_class 테이블 같은경우,

2000개의 스키마에 각 스키마 안에는 100여개의 테이블이 있고, 그테이블에 부가적으로 사용되는 인덱스가 서너개있고, 이런식으로 계산하면, pg_class 테이블이 감당해야할 객체수(pg_class의 row수가 되겠지요)는 약 50만개를 육박할겝니다. 이렇게 시스템 카타로그 테이블 자체가 커졌을 때, 과연 DB서버가 무난하게 잘 돌아갈지는 의문입니다. 이건 뚜껑을 열어봐야 알 수 있을 듯싶네요.

일이 잘 풀려 돈 많이 벌게 되면, 이곳에 꼭 성공사례를 남겨두시면, 많은 분들이 도움을 받을 듯싶네요. :)