Целта на оваа статија е да се користи примерот на библиотека чувар на шема покажуваат алатки кои можат значително да го поедностават процесот на развивање бази на податоци во рамките на PHP проектите со користење на PostgreSQL DBMS.

Информациите од оваа статија, пред сè, ќе бидат корисни за програмерите кои сакаат максимално да ги искористат можностите на PostgreSQL, но се соочуваат со проблеми со одржување на деловната логика поставена во базата на податоци.

Оваа статија нема да ги опише предностите или недостатоците на складирањето на деловната логика во базата на податоци. Се претпоставува дека изборот е веќе направен од читателот.

Следниве прашања ќе бидат разгледани:

1. Во каква форма треба да се складира депонијата на структурата на базата на податоци во систем за контрола на верзии (во натамошниот текст VCS)
2. Како да ги следите промените во структурата на базата на податоци по зачувување на депонија
3. Како да се префрлат промените во структурата на базата на податоци во други средини без конфликти и џиновски датотеки за миграција
4. Како да се организира процесот на паралелна работа на проект од неколку програмери
5. Како безбедно да се распоредат повеќе промени во структурата на базата на податоци во производствената средина
   

   SchemaKeeper дизајниран за работа со складирани процедури напишани на јазикот PL/pgSQL. Тестирањето со други јазици не е спроведено, така што употребата можеби нема да биде толку ефективна или можеби не е возможна.

Како да складирате депонија на структурата на базата на податоци во VCS

Библиотека чувар на шема обезбедува функција saveDump, што ја зачувува структурата на сите објекти од базата на податоци како посебни текстуални датотеки. Излезот е директориум што ја содржи структурата на базата на податоци, поделена на групирани датотеки што може лесно да се додадат во VCS.

Ајде да погледнеме како да ги конвертираме објектите од базата на податоци во датотеки користејќи неколку примери:

Тип на објект
Шемата
Име
Релативна патека до датотеката

маса
јавниот
сметки
./public/tables/accounts.txt

Складирана процедура
јавниот
авт (хаш бигинт)
./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. По завршувањето на задачата, развивачот ја повикува функцијата saveDumpда се извршат промени направени во базата на податоци во VCS
4. Рестартирање на програмерите refresh.sh, тогаш verifyDumpкој сега прикажува листа на промени што треба да се вклучат во миграцијата
5. Програмерот ги пренесува сите промени во структурата во датотеката за миграција, работи повторно refresh.sh и verifyDump, и, ако миграцијата е правилно составена, verifyDump нема да покаже никакви разлики помеѓу локалната база на податоци и зачуваната депонија

Процесот опишан погоре е компатибилен со принципите на gitflow. Секоја гранка во VCS ќе содржи своја верзија на депонијата, а при спојување на гранки, депонии ќе се спојат. Во повеќето случаи, не треба да се преземат дополнителни дејствија по спојувањето, но ако се направат промени на различни гранки, на пример во иста табела, може да дојде до конфликт.

Ајде да разгледаме конфликтна ситуација користејќи пример: има гранка развој на, од која се разгрануваат две гранки: функција1 и функција2, кои немаат конфликти со развој на, но имаат конфликти едни со други. Задачата е да се спојат двете гранки во развој на. За овој случај, се препорачува прво да се спои една од гранките во развој наа потоа се спојуваат развој на до преостанатата гранка, разрешување на конфликти во преостанатата гранка, а потоа спојување на последната гранка во развој на. За време на фазата на решавање на конфликтот, можеби ќе треба да ја поправите датотеката за миграција во последната гранка, така што ќе се совпадне со последната депонија, која ги вклучува резултатите од спојувањата.

Како безбедно да се распоредат повеќе промени во структурата на базата на податоци во производствената средина

Благодарение на присуството на депонија на тековната структура на базата на податоци во VCS, станува возможно да се провери производната база на податоци за точна усогласеност со потребната структура. Ова осигурува дека сите промени што ги планирале програмерите биле успешно префрлени во производствената база.

Како ДДЛ во PostgreSQL е трансакциска, се препорачува да се придржувате до следниов редослед за распоредување, за во случај на неочекувана грешка, да можете „безболно“ да извршите ROLLBACK:

1. Започнете трансакција
2. Извршете ги сите миграции во трансакција
3. Во истата трансакција, извршете deployDump
4. Без да ја завршите трансакцијата, извршете verifyDump. Ако нема грешки, стартувајте COMMIT. Ако има грешки, стартувајте ROLLBACK

Овие чекори може лесно да се интегрираат во постоечките пристапи за распоредување на апликациите, вклучително и нула прекин.

Заклучок

Благодарение на методите опишани погоре, можно е да се исцедат максималните перформанси од проектите „PHP + PostgreSQL“, притоа жртвувајќи релативно мала погодност за развој во споредба со спроведувањето на целата деловна логика во главниот код на апликацијата. Покрај тоа, обработката на податоците во PL/pgSQL често изгледа потранспарентно и бара помалку код од истата функционалност напишана во PHP.

Извор: www.habr.com