이 기사의 목적은 라이브러리의 예를 사용하는 것입니다. 스키마 키퍼 PostgreSQL DBMS를 사용하여 PHP 프로젝트 내에서 데이터베이스 개발 프로세스를 크게 단순화할 수 있는 도구를 보여줍니다.

이 기사의 정보는 우선 PostgreSQL 기능을 최대한 활용하고 싶지만 데이터베이스에 배치된 비즈니스 논리를 유지하는 데 문제가 있는 개발자에게 유용할 것입니다.

이 문서에서는 데이터베이스에 비즈니스 논리를 저장하는 것의 장점이나 단점을 설명하지 않습니다. 독자가 이미 선택을 했다고 가정합니다.

다음과 같은 질문이 고려될 것입니다:

1. 데이터베이스 구조 덤프는 버전 관리 시스템(이하 VCS)에 어떤 형식으로 저장되어야 합니까?
2. 덤프를 저장한 후 데이터베이스 구조의 변경 사항을 추적하는 방법
3. 충돌이나 대규모 마이그레이션 파일 없이 데이터베이스 구조의 변경 사항을 다른 환경으로 전송하는 방법
4. 여러 개발자가 프로젝트에 대한 병렬 작업 프로세스를 구성하는 방법
5. 데이터베이스 구조의 더 많은 변경 사항을 프로덕션 환경에 안전하게 배포하는 방법
   

   스키마키퍼 언어로 작성된 저장 프로시저 작업을 위해 설계되었습니다. PL / pgSQL. 다른 언어에 대한 테스트는 진행되지 않았으므로 사용이 효과적이지 않거나 불가능할 수 있습니다.

VCS에 데이터베이스 구조 덤프를 저장하는 방법

도서관 스키마 키퍼 기능을 제공합니다 saveDump, 데이터베이스의 모든 개체 구조를 별도의 텍스트 파일로 저장합니다. 출력은 VCS에 쉽게 추가할 수 있는 그룹화된 파일로 구분된 데이터베이스 구조를 포함하는 디렉토리입니다.

몇 가지 예를 사용하여 데이터베이스의 개체를 파일로 변환하는 방법을 살펴보겠습니다.

개체 유형
계획
이름
파일의 상대 경로

테이블
공개
계정
./public/tables/accounts.txt

저장 프로시저
공개
인증(해시 bigint)
./public/functions/auth(int8).sql

소개
예약
관세
./booking/views/tariffs.txt

파일의 내용은 특정 데이터베이스 개체의 구조를 텍스트로 표현한 것입니다. 예를 들어 저장 프로시저의 경우 파일 내용은 블록으로 시작하여 저장 프로시저의 전체 정의가 됩니다. CREATE OR REPLACE FUNCTION.

위 표에서 볼 수 있듯이 파일 경로에는 해당 객체의 유형, 스키마, 이름에 대한 정보가 저장됩니다. 이 접근 방식을 사용하면 데이터베이스 변경 사항의 덤프 및 코드 검토를 더 쉽게 탐색할 수 있습니다.

신장 .sql 저장 프로시저 소스 코드가 있는 파일의 경우 파일이 열릴 때 IDE가 데이터베이스와 상호 작용하기 위한 도구를 자동으로 제공하도록 이 옵션이 선택되었습니다.

덤프를 저장한 후 데이터베이스 구조의 변경 사항을 추적하는 방법

현재 데이터베이스 구조의 덤프를 VCS에 저장하면 덤프가 생성된 후 데이터베이스 구조가 변경되었는지 확인할 수 있습니다. 도서관에서 스키마 키퍼 데이터베이스 구조의 변화를 감지하는 기능이 제공됩니다 verifyDump, 부작용 없이 차이점에 대한 정보를 반환합니다.

확인하는 또 다른 방법은 함수를 다시 호출하는 것입니다. saveDump, 동일한 디렉토리를 지정하고 VCS에서 변경 사항을 확인합니다. 데이터베이스의 모든 객체는 별도의 파일에 저장되므로 VCS는 변경된 객체만 표시합니다.
이 방법의 가장 큰 단점은 변경 사항을 보려면 파일을 덮어써야 한다는 것입니다.

충돌이나 대규모 마이그레이션 파일 없이 데이터베이스 구조의 변경 사항을 다른 환경으로 전송하는 방법

기능 덕분에 deployDump 저장 프로시저의 소스 코드는 일반 애플리케이션 소스 코드와 동일한 방식으로 편집할 수 있습니다. 저장 프로시저 코드에서 새 줄을 추가/삭제하고 변경 사항을 버전 제어에 즉시 푸시하거나 덤프 디렉터리에서 해당 파일을 생성/삭제하여 저장 프로시저를 생성/삭제할 수 있습니다.

예를 들어 스키마에 새 저장 프로시저를 생성하려면 public 확장자를 가진 새 파일을 만드세요 .sql 디렉토리에서 public/functions, 블록을 포함하여 저장 프로시저의 소스 코드를 그 안에 넣습니다. CREATE OR REPLACE FUNCTION, 그런 다음 함수를 호출하십시오. deployDump. 저장 프로시저 수정 및 삭제도 같은 방식으로 발생합니다. 따라서 코드는 VCS와 데이터베이스에 동시에 들어갑니다.

저장 프로시저의 소스 코드에 오류가 나타나거나 파일 이름과 저장 프로시저 이름이 일치하지 않는 경우 deployDump 실패하고 오류 텍스트가 표시됩니다. 덤프를 사용할 때 덤프와 현재 데이터베이스 간의 저장 프로시저 불일치가 불가능합니다. deployDump.

새 저장 프로시저를 생성할 때 올바른 파일 이름을 수동으로 입력할 필요가 없습니다. 파일 확장자가 있으면 충분합니다. .sql. 통화 후 deployDump 오류 텍스트에는 파일 이름을 바꾸는 데 사용할 수 있는 올바른 이름이 포함됩니다.

deployDump 추가 작업 없이 함수 또는 반환 유형의 매개변수를 변경할 수 있지만, 고전적인 접근 방식을 사용하면
먼저 실행 DROP FUNCTION, 그리고 나서야 CREATE OR REPLACE FUNCTION.

불행히도 다음과 같은 몇 가지 상황이 있습니다. deployDump 변경 사항을 자동으로 적용할 수 없습니다. 예를 들어, 하나 이상의 트리거에서 사용되는 트리거 기능이 제거되는 경우입니다. 이러한 상황은 마이그레이션 파일을 사용하여 수동으로 해결됩니다.

저장 프로시저에 대한 변경 사항 마이그레이션을 담당하는 경우 스키마 키퍼, 구조의 다른 변경 사항을 전송하려면 마이그레이션 파일을 사용해야 합니다. 예를 들어 마이그레이션 작업을 위한 좋은 라이브러리는 다음과 같습니다. 교리/이주.

출시 전에 마이그레이션을 적용해야 합니다. deployDump. 이를 통해 구조를 모두 변경하고 문제 상황을 해결할 수 있으므로 저장 프로시저의 변경 내용이 이후에 문제 없이 전송됩니다.

마이그레이션 작업은 다음 섹션에서 더 자세히 설명됩니다.

여러 개발자가 프로젝트에 대한 병렬 작업 프로세스를 구성하는 방법

개발자가 작업 시스템에서 실행하여 VCS에 저장된 덤프에 따라 로컬 데이터베이스의 구조를 가져오는 데이터베이스의 전체 초기화를 위한 스크립트를 작성해야 합니다. 가장 쉬운 방법은 로컬 데이터베이스 초기화를 3단계로 나누는 것입니다.

1. 예를 들어 다음과 같은 기본 구조를 가진 파일을 가져옵니다. base.sql
2. 마이그레이션 적용
3. 도전 deployDump

base.sql 마이그레이션이 적용되고 실행되는 시작점입니다. deployDump즉, base.sql + миграции + deployDump = актуальная структура БД. 유틸리티를 사용하여 이러한 파일을 만들 수 있습니다 pg_dump. 사용된 base.sql 데이터베이스를 처음부터 초기화하는 경우에만 해당됩니다.

완전한 데이터베이스 초기화를 위해 스크립트를 호출해 보겠습니다. refresh.sh. 워크플로는 다음과 같습니다.

1. 개발자가 자신의 환경에서 시작합니다. refresh.sh 현재 데이터베이스 구조를 가져옵니다.
2. 개발자는 당면한 작업에 대한 작업을 시작하고 새로운 기능의 요구 사항을 충족하도록 로컬 데이터베이스를 수정합니다(ALTER TABLE ... ADD COLUMN 기타)
3. 작업을 완료한 후 개발자는 함수를 호출합니다. saveDumpVCS의 데이터베이스에 대한 변경 사항을 커밋합니다.
4. 개발자 재출시 refresh.sh, 그 다음에 verifyDump이제 마이그레이션에 포함할 변경 사항 목록이 표시됩니다.
5. 개발자는 모든 구조 변경 사항을 마이그레이션 파일로 전송하고 다시 실행합니다. refresh.sh и verifyDump, 마이그레이션이 올바르게 컴파일되면 verifyDump 로컬 데이터베이스와 저장된 덤프 간에 차이가 표시되지 않습니다.

위에서 설명한 프로세스는 gitflow 원칙과 호환됩니다. VCS의 각 분기에는 자체 버전의 덤프가 포함되며 분기를 병합하면 덤프도 병합됩니다. 대부분의 경우 병합 후에는 추가 작업을 수행할 필요가 없지만, 다른 분기(예: 동일한 테이블)에서 변경이 이루어진 경우 충돌이 발생할 수 있습니다.

예를 사용하여 충돌 상황을 고려해 보겠습니다. 분기가 있습니다. 개발, 두 개의 가지가 분기됩니다. feature1 и feature2, 다음과 충돌하지 않습니다. 개발, 하지만 서로 충돌이 발생합니다. 임무는 두 가지를 모두 병합하는 것입니다. 개발. 이 경우 먼저 분기 중 하나를 병합하는 것이 좋습니다. 개발그런 다음 병합 개발 나머지 분기에 충돌을 해결하고 마지막 분기를 병합합니다. 개발. 충돌 해결 단계 중에 병합 결과가 포함된 최종 덤프와 일치하도록 마지막 분기의 마이그레이션 파일을 수정해야 할 수도 있습니다.

데이터베이스 구조의 더 많은 변경 사항을 프로덕션 환경에 안전하게 배포하는 방법

VCS에 현재 데이터베이스 구조의 덤프가 있으므로 프로덕션 데이터베이스가 필요한 구조를 정확히 준수하는지 확인할 수 있습니다. 이를 통해 개발자가 의도한 모든 변경 사항이 프로덕션 기반으로 성공적으로 전송되었는지 확인할 수 있습니다.

으로 DDL PostgreSQL에서는 거래상의, 예기치 않은 오류가 발생하는 경우 "고통 없이" 실행할 수 있도록 다음 배포 순서를 따르는 것이 좋습니다. ROLLBACK:

1. 거래 시작
2. 트랜잭션에서 모든 마이그레이션 수행
3. 동일한 트랜잭션에서 실행 deployDump
4. 거래를 완료하지 않고 실행 verifyDump. 오류가 없으면 실행 COMMIT. 오류가 있으면 실행하세요. ROLLBACK

이러한 단계는 가동 중지 시간을 포함하여 애플리케이션 배포에 대한 기존 접근 방식에 쉽게 통합될 수 있습니다.

결론

위에서 설명한 방법 덕분에 “PHP + PostgreSQL” 프로젝트에서 최대 성능을 끌어내는 것이 가능하며, 메인 애플리케이션 코드에서 모든 비즈니스 로직을 구현하는 것에 비해 상대적으로 개발 편의성을 거의 희생하지 않습니다. 또한, 데이터 처리 PL / pgSQL PHP로 작성된 동일한 기능보다 더 투명해 보이고 더 적은 코드가 필요한 경우가 많습니다.

출처 : habr.com