주석으로 PostgreSQL 스키마를 버전 제어하는 ​​방법은 무엇입니까?


9

코드, 문서, 시스템 구성 : Git 작업의 대부분을 버전 관리 합니다. 내 소중한 모든 작업이 텍스트 파일로 저장되기 때문에 그렇게 할 수 있습니다.

또한 Postgres 데이터베이스를위한 많은 SQL 스키마를 작성하고 다루었습니다. 이 스키마에는 뷰, SQL 함수가 포함되어 있으며 Postgres 함수를 R 프로그래밍 언어 ( PL / R을 통해 )로 작성합니다.

본인과 공동 작업자가 작성하는 청크 스키마를 복사하여 지나치려고했지만 그렇게하는 것을 잊었습니다. 복사 및 과거 작업은 반복적이고 오류가 발생하기 쉽습니다.

pg_dump / pg_restore 메소드는 주석을 풀기 때문에 작동하지 않습니다.

이상적으로는 현재 스키마를 파일로 추출하고 주석을 보존하여 버전 제어를 수행 할 수있는 방법을 원합니다.

주석이있는 버전 관리 스키마에 대한 모범 사례는 무엇입니까?


2
나는 질문이 psql과 관련이 있다고 생각하지 않습니다. SO stackoverflow.com/… 에서 일부 답변을 읽었 습니까? 당신을 위해 뭔가가있을 수 있습니다.
DrColossos

@ DrColossos-이러한 질문 중 일부는 좋은 마이그레이션 후보입니다.
CoderHawk

@DrColossos는 COMMENT ONpostgres가 아닌 환경에서 사용할 수 있습니까? 표준 SQL 이라고 생각 하지 않습니다 . 이는 postgres에 따라 다를 있음 을 의미합니다 .
xenoterracide

@xenoterracide 당신은 맞습니다. 저는 데이터베이스 자체의 버전 관리 문제에 대해 더 많이 이야기하고있었습니다
DrColossos

답변:


9

주석에 스키마가 COMMENT ON있는 다양한 SCHEMA구성 요소를 사용하여 덤프 하지 않는 이유는 무엇입니까?

COMMENT는 데이터베이스 객체에 대한 주석을 저장합니다.
주석을 수정하려면 동일한 오브젝트에 대해 새 COMMENT 명령을 발행하십시오. 각 객체에 대해 하나의 주석 문자열 만 저장됩니다. 주석을 제거하려면 텍스트 문자열 대신 NULL을 작성하십시오. 객체를 놓으면 주석이 자동으로 삭제됩니다.


정말 도움이되었지만 모범 사례 답변을 받기를 원하기 때문에 아직 답변으로 표시하고 싶지 않습니다.
Aleksandr Levchuk

2

버전 관리 스키마는 항상 문제가되었습니다. 일반적으로 사용중인 데이터 모델링 도구로 생성 된 스키마를 버전 관리합니다. 모델도 버전 제어됩니다. 현재 스키마와 이전 스키마 사이의 차이를 사용하여 스키마를 업데이트하는 데 필요한 패치를 작성합니다. 일부 모델링 도구는 사용 가능한 스키마 업데이트 스크립트를 생성합니다. 업데이트 스크립트도 버전 제어됩니다.

때때로 스키마를 재생성하기에 적합한 형식으로 스키마를 덤프하기위한 스크립트가 나타납니다. 이것들 중 하나가 당신이 찾고있는 것일 수 있습니다. 일부 모델링 및 쿼리 도구는 기존 스키마에서 스키마 재생 스크립트를 생성 할 수 있습니다. 이를 스크립팅 할 수 있으면 버전 관리에 적합한 파일이 제공 될 수 있습니다.


2

이전 제안에 대한 대안 (또는 이들을 결합 할 수 있음)은 SQL 코드를 편집기 (IDE)에 작성하고 파일을 저장하고 VCS에 커밋 한 다음을 사용하여 데이터베이스에서 코드를 실행하는 것 psql -1f입니다. 이렇게하면 코드가 실행되기 전에 버전이 제어됩니다.


"이런 방식으로 코드가 실행되기 전에 버전이 제어됩니다." 그리고 그래야합니다.
Mike Sherrill 'Cat Recall'3

@ catcall 예. 그러나 ops 게시물을 읽으면 그럴 것이라고 생각하지 않습니다.
xenoterracide

불행히도 내가 본 대부분의 장소에서는 그렇지 않습니다. 그러나 테스트하는 코드와 QA가 프로덕션으로 이동하는 코드와 동일하다는 것을 보장하는 유일한 방법입니다. "true"데이터베이스가 DBMS가 아닌 VCS에 있다는 아이디어는 널리 퍼져 있지 않습니다.
Mike Sherrill 'Cat Recall'11

0

나는 비슷한 프로젝트에서 일하고 있습니다. 이것은 내 디자인 제안입니다.

  1. 정기적으로 DB 객체를 주석 처리하면 매 2 주 또는 2 개월마다 말할 수 있습니다.
  2. pg_dump all을 수행 하십시오 (예 : 모든 세부 사항과 관계를 확실히하기 위해 모든 것을 확보하십시오). yyyymmdd-VERSION.dump로 이름을 지정하십시오.
  3. Git을 사용하는 경우 큰 파일에 플러그인을 사용 하십시오.
  4. repo를 사용하지 않는 경우 아래 표와 같이 텍스트 .CSV 형식으로 간단한 표를 작성하십시오.

    version | file name | date | description | 1.0 | yyyymmdd-v10.dump | yyyymmdd | new version of user table | 1.1 | backupDB-v11.dump | yyyymmdd | normalized reports tables |

  5. 파일 이름으로 생성 된 덤프의 CSV 파일에 관계를 유지함으로써 어떻게 든 쉽게 추적 할 수 있으며 모든 것을 완전히 덤프했기 때문에 복원이 작동하는지 확인합니다.

오늘날 클라우드 스토리지 또는 온 사이트 스토리지는 TB 데이터에 대해 이야기하더라도 비용이 너무 많이 들지 않아야합니다. 최대 16TB의 700 ~ 1000 USD의 격노가 있습니다 .

가장 인기있는 AWS S3 와 같은 스토리지 클라우드로 이동하면 $$$를 훨씬 더 절약 할 수 있습니다

좋은 디자인과 조직의 표준이 일단 구현되면 고통스럽지 않아야하는 모든 IT 인프라와 자산을 추적하도록 정의 된 경우 비교적 간단하고 구성의 어려움과 가장 중요한 시간을 절약 할 수 있습니다 ...

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.