Այս հոդվածի նպատակն է օգտագործել գրադարանի օրինակը սխեմա-պահապան ցույց տալ գործիքներ, որոնք կարող են զգալիորեն պարզեցնել PHP նախագծերում տվյալների բազաների մշակման գործընթացը՝ օգտագործելով PostgreSQL DBMS:

Այս հոդվածի տեղեկատվությունը, առաջին հերթին, օգտակար կլինի այն մշակողների համար, ովքեր ցանկանում են առավելագույնս օգտագործել PostgreSQL հնարավորությունները, բայց բախվում են տվյալների բազայում տեղադրված բիզնես տրամաբանությունը պահպանելու հետ կապված խնդիրների հետ:

Այս հոդվածը չի նկարագրի բիզնես տրամաբանությունը տվյալների բազայում պահելու առավելություններն ու թերությունները: Ենթադրվում է, որ ընտրությունն արդեն կատարել է ընթերցողը։

Դիտարկվելու են հետևյալ հարցերը.

1. Ինչ ձևով պետք է տվյալների բազայի կառուցվածքի աղբանոցը պահվի տարբերակների կառավարման համակարգում (այսուհետ՝ VCS)
2. Ինչպես հետևել տվյալների բազայի կառուցվածքի փոփոխություններին աղբավայրը պահելուց հետո
3. Ինչպես փոխանցել տվյալների բազայի կառուցվածքի փոփոխությունները այլ միջավայրեր՝ առանց կոնֆլիկտների և հսկա միգրացիոն ֆայլերի
4. Ինչպես կազմակերպել մի քանի մշակողների կողմից նախագծի վրա զուգահեռ աշխատանքի գործընթացը
5. Ինչպես ապահով կերպով տեղակայել տվյալների բազայի կառուցվածքում ավելի շատ փոփոխություններ արտադրական միջավայրում
   

   SchemaKeeper նախատեսված է լեզվով գրված պահպանված ընթացակարգերի հետ աշխատելու համար PL/pgSQL. Այլ լեզուներով թեստավորում չի իրականացվել, ուստի օգտագործումը կարող է լինել այնքան արդյունավետ կամ հնարավոր չէ:

Ինչպես պահել տվյալների բազայի կառուցվածքի աղբանոցը VCS-ում

գրադարան սխեմա-պահապան ապահովում է գործառույթ saveDump, որը պահպանում է բոլոր օբյեկտների կառուցվածքը տվյալների բազայից որպես առանձին տեքստային ֆայլեր։ Արդյունքը տվյալների բազայի կառուցվածքը պարունակող գրացուցակ է՝ բաժանված խմբավորված ֆայլերի, որոնք հեշտությամբ կարող են ավելացվել VCS-ում:

Եկեք նայենք օբյեկտները տվյալների բազայից ֆայլերի վերածելուն՝ օգտագործելով մի քանի օրինակ.

Օբյեկտի տեսակը
Ծրագիրը
Անվանում
Ֆայլի հարաբերական ուղին

սեղան
հասարակություն
Հաշիվներ
./public/tables/accounts.txt

Պահպանված ընթացակարգ
հասարակություն
auth (հեշ բիգինտ)
./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-ի յուրաքանչյուր ճյուղ կպարունակի աղբավայրի իր տարբերակը, և ճյուղերի միաձուլման ժամանակ աղբավայրերը կմիավորվեն: Շատ դեպքերում, միաձուլումից հետո լրացուցիչ գործողությունների կարիք չկա, բայց եթե փոփոխություններ են կատարվել տարբեր ճյուղերում, օրինակ՝ նույն սեղանի շուրջ, կարող է կոնֆլիկտ առաջանալ:

Դիտարկենք կոնֆլիկտային իրավիճակը՝ օգտագործելով օրինակ՝ ճյուղ կա զարգանալ, որից ճյուղավորվում են երկու ճյուղ. առանձնահատկություն1 и առանձնահատկություն2, որոնց հետ հակասություններ չունեն զարգանալ, բայց ունեն կոնֆլիկտներ միմյանց հետ։ Խնդիրն այն է, որ երկու ճյուղերը միավորվեն զարգանալ. Այս դեպքում խորհուրդ է տրվում նախ միացնել ճյուղերից մեկը զարգանալիսկ հետո միաձուլվել զարգանալ դեպի մնացած ճյուղը, լուծելով հակամարտությունները մնացած ճյուղում, իսկ հետո միաձուլելով վերջին ճյուղը զարգանալ. Հակամարտությունների լուծման փուլում դուք կարող եք ստիպված լինել շտկել միգրացիոն ֆայլը վերջին ճյուղում, որպեսզի այն համապատասխանի վերջնական աղբարկղին, որը ներառում է միաձուլումների արդյունքները:

Ինչպես ապահով կերպով տեղակայել տվյալների բազայի կառուցվածքում ավելի շատ փոփոխություններ արտադրական միջավայրում

VCS-ում տվյալների բազայի ընթացիկ կառուցվածքի աղբանոցի առկայության շնորհիվ հնարավոր է դառնում ստուգել արտադրության տվյալների բազան՝ պահանջվող կառուցվածքին ճշգրիտ համապատասխանության համար: Սա ապահովում է, որ բոլոր փոփոխությունները, որոնք մշակողները նախատեսել էին, հաջողությամբ փոխանցվեցին արտադրական բազա:

Ինչպես DDL PostgreSQL-ում է գործարքային, խորհուրդ է տրվում պահպանել հետևյալ տեղակայման կարգը, որպեսզի անսպասելի սխալի դեպքում կարողանաք «անցավ» կատարել. ROLLBACK:

1. Գործարք սկսել
2. Կատարեք բոլոր միգրացիաները գործարքի մեջ
3. Նույն գործարքում կատարել deployDump
4. Առանց գործարքն ավարտելու, կատարեք verifyDump. Եթե ​​սխալներ չկան, վազեք COMMIT. Եթե ​​կան սխալներ, վազեք ROLLBACK

Այս քայլերը կարող են հեշտությամբ ինտեգրվել հավելվածների տեղակայման առկա մոտեցումներին, ներառյալ զրոյական դադարը:

Ամփոփում

Վերը նկարագրված մեթոդների շնորհիվ հնարավոր է սեղմել «PHP + PostgreSQL» նախագծերի առավելագույն արդյունավետությունը՝ միաժամանակ զոհաբերելով զարգացման համեմատաբար քիչ հարմարավետությունը՝ համեմատած հիմնական հավելվածի կոդում ամբողջ բիզնես տրամաբանության իրականացման հետ: Ավելին, տվյալների մշակումը ներս PL/pgSQL հաճախ ավելի թափանցիկ է թվում և պահանջում է ավելի քիչ կոդ, քան PHP-ում գրված նույն ֆունկցիոնալությունը:

Source: www.habr.com