Die doel van hierdie artikel is om die voorbeeld van 'n biblioteek te gebruik skema-houer wys gereedskap wat die proses van die ontwikkeling van databasisse binne PHP-projekte aansienlik kan vereenvoudig deur die PostgreSQL DBMS te gebruik.

Die inligting uit hierdie artikel sal eerstens nuttig wees vir ontwikkelaars wat die meeste van PostgreSQL-vermoëns wil benut, maar gekonfronteer word met probleme met die handhawing van besigheidslogika wat in die databasis geplaas is.

Hierdie artikel sal nie die voordele of nadele van die stoor van besigheidslogika in 'n databasis beskryf nie. Daar word aanvaar dat die keuse reeds deur die leser gemaak is.

Die volgende vrae sal oorweeg word:

1. In watter vorm moet 'n databasisstruktuurstorting gestoor word in 'n weergawebeheerstelsel (hierna verwys as VCS)
2. Hoe om veranderinge in die databasisstruktuur op te spoor nadat 'n storting gestoor is
3. Hoe om veranderinge in die databasisstruktuur na ander omgewings oor te dra sonder konflikte en reuse-migrasielêers
4. Hoe om die proses van parallelle werk aan 'n projek deur verskeie ontwikkelaars te organiseer
5. Hoe om meer veranderinge in die databasisstruktuur veilig na 'n produksie-omgewing te ontplooi
   

   SchemaKeeper ontwerp om te werk met gestoorde prosedures wat in die taal geskryf is PL/pgSQL. Toetsing met ander tale is nie uitgevoer nie, so gebruik is dalk nie so effektief nie of dalk nie moontlik nie.

Hoe om 'n databasisstruktuurstorting in VCS te stoor

Biblioteek skema-houer bied 'n funksie saveDump, wat die struktuur van alle voorwerpe van die databasis as aparte tekslêers stoor. Die uitvoer is 'n gids wat die databasisstruktuur bevat, verdeel in gegroepeerde lêers wat maklik by VCS gevoeg kan word.

Kom ons kyk na die omskakeling van voorwerpe vanaf 'n databasis in lêers deur verskeie voorbeelde te gebruik:

Tipe voorwerp
Die skema
Naam
Relatiewe pad na lêer

tafel
openbare
rekeninge
./public/tables/accounts.txt

Gebergde prosedure
openbare
auth (hash bigint)
./public/functions/auth(int8).sql

idee
bespreking
tariewe
./booking/views/tariffs.txt

Die inhoud van die lêers is 'n tekstuele voorstelling van die struktuur van 'n spesifieke databasisobjek. Byvoorbeeld, vir gestoorde prosedures, sal die inhoud van die lêer die volledige definisie van die gestoorde prosedure wees, wat begin met die blok CREATE OR REPLACE FUNCTION.

Soos uit die tabel hierbo gesien kan word, stoor die pad na die lêer inligting oor die tipe, skema en naam van die voorwerp. Hierdie benadering maak dit makliker om deur die stortings- en kodehersiening van veranderinge in die databasis te navigeer.

uitbreiding .sql vir lêers met gestoorde prosedure-bronkode, is dit gekies sodat die IDE outomaties gereedskap verskaf vir interaksie met die databasis wanneer die lêer oopgemaak word.

Hoe om veranderinge in die databasisstruktuur op te spoor nadat 'n storting gestoor is

Deur 'n storting van die huidige databasisstruktuur in VCS te stoor, kry ons die geleentheid om te kyk of veranderinge aan die databasisstruktuur aangebring is nadat die stortingsterrein geskep is. In biblioteek skema-houer om veranderinge in die databasisstruktuur op te spoor, word 'n funksie verskaf verifyDump, wat inligting oor die verskille sonder newe-effekte gee.

'n Alternatiewe manier om na te gaan, is om die funksie weer te bel saveDump, spesifiseer dieselfde gids, en kyk in VCS vir veranderinge. Aangesien alle voorwerpe van die databasis in aparte lêers gestoor word, sal VCS slegs veranderde voorwerpe wys.
Die grootste nadeel van hierdie metode is die behoefte om lêers te oorskryf om die veranderinge te sien.

Hoe om veranderinge in die databasisstruktuur na ander omgewings oor te dra sonder konflikte en reuse-migrasielêers

Danksy die funksie deployDump Die bronkode van gestoorde prosedures kan op presies dieselfde manier as die gewone toepassingsbronkode geredigeer word. Jy kan nuwe reëls in gestoorde prosedure-kode byvoeg/skrap en veranderinge onmiddellik aan weergawebeheer stoot, of gestoorde prosedures skep/vee deur die ooreenstemmende lêers in die dump-gids te skep/skrap.

Byvoorbeeld, om 'n nuwe gestoorde prosedure in 'n skema te skep public skep net 'n nuwe lêer met die uitbreiding .sql in die gids public/functions, plaas die bronkode van die gestoorde prosedure daarin, insluitend die blok CREATE OR REPLACE FUNCTION, roep dan die funksie deployDump. Die wysiging en uitvee van 'n gestoorde prosedure vind op dieselfde manier plaas. Dus, die kode gaan in beide die VCS en die databasis op dieselfde tyd.

As 'n fout in die bronkode van enige gestoorde prosedure voorkom, of 'n verskil tussen die name van die lêer en die gestoorde prosedure, dan deployDump sal misluk, wat foutteks vertoon. Mispassing van gestoorde prosedures tussen die storting en die huidige databasis is onmoontlik wanneer dit gebruik word deployDump.

Wanneer 'n nuwe gestoorde prosedure geskep word, is dit nie nodig om die korrekte lêernaam handmatig in te voer nie. Dit is genoeg vir die lêer om die uitbreiding te hê .sql. Na die oproep deployDump die foutteks sal die korrekte naam bevat, wat gebruik kan word om die lêer te hernoem.

deployDump laat jou toe om die parameters van 'n funksie of terugkeertipe te verander sonder bykomende aksies, terwyl jy met die klassieke benadering sal moet
eers uitvoer DROP FUNCTION, en dan eers CREATE OR REPLACE FUNCTION.

Ongelukkig is daar 'n paar situasies waar deployDump nie in staat om veranderinge outomaties toe te pas nie. Byvoorbeeld, as 'n snellerfunksie wat deur ten minste een sneller gebruik word, verwyder word. Sulke situasies word met die hand opgelos deur migrasielêers te gebruik.

As jy verantwoordelik is vir die migreer van veranderinge na gestoorde prosedures skema-houer, dan moet migrasielêers gebruik word om ander veranderinge in die struktuur oor te dra. Byvoorbeeld, 'n goeie biblioteek om met migrasies te werk is leerstelling/migrasies.

Migrasies moet voor bekendstelling toegepas word deployDump. Dit laat jou toe om alle veranderinge aan die struktuur aan te bring en problematiese situasies op te los sodat veranderinge in gestoorde prosedures daarna sonder probleme oorgedra word.

Werk met migrasies sal in meer besonderhede in die volgende afdelings beskryf word.

Hoe om die proses van parallelle werk aan 'n projek deur verskeie ontwikkelaars te organiseer

Dit is nodig om 'n skrip te skep vir die volledige inisialisering van die databasis, wat deur die ontwikkelaar op sy werkmasjien geloods sal word, wat die struktuur van die plaaslike databasis in ooreenstemming bring met die storting wat in VCS gestoor is. Die maklikste manier is om die inisialisering van die plaaslike databasis in 3 stappe te verdeel:

1. Voer 'n lêer in met 'n basiese struktuur wat bv. base.sql
2. Pas migrasies toe
3. oproep deployDump

base.sql is die beginpunt waarop migrasies toegepas en uitgevoer word deployDumpDit is, base.sql + миграции + deployDump = актуальная структура БД. Jy kan so 'n lêer skep met die hulpprogram pg_dump. Gebruik base.sql uitsluitlik wanneer die databasis van nuuts af geïnisialiseer word.

Kom ons noem die skrif vir volledige databasis-inisialisering refresh.sh. Die werkvloei kan soos volg lyk:

1. Die ontwikkelaar begin in sy omgewing refresh.sh en kry die huidige databasisstruktuur
2. Die ontwikkelaar begin werk aan die taak op hande, en wysig die plaaslike databasis om aan die behoeftes van die nuwe funksionaliteit te voldoen (ALTER TABLE ... ADD COLUMN ens)
3. Nadat die taak voltooi is, roep die ontwikkelaar die funksie saveDumpom veranderinge aan die databasis in VCS te pleeg
4. Ontwikkelaar herbegin refresh.shdan verifyDumpwat nou 'n lys wysigings wys om by die migrasie in te sluit
5. Die ontwikkelaar dra alle struktuurveranderinge na die migrasielêer oor, loop weer refresh.sh и verifyDump, en, as die migrasie korrek saamgestel is, verifyDump sal geen verskille tussen die plaaslike databasis en die gestoorde stortingsterrein wys nie

Die proses hierbo beskryf is versoenbaar met gitflow-beginsels. Elke tak in die VCS sal sy eie weergawe van die stortingsterrein bevat, en wanneer takke saamgevoeg word, sal die stortingsterreine saamgevoeg word. In die meeste gevalle hoef geen bykomende stappe geneem te word na 'n samesmelting nie, maar as veranderinge in verskillende takke aangebring is, byvoorbeeld aan dieselfde tabel, kan 'n konflik ontstaan.

Kom ons kyk na 'n konfliksituasie deur 'n voorbeeld te gebruik: daar is 'n tak ontwikkel, waaruit twee takke vertak: funksie1 и funksie2, wat geen konflik met ontwikkel, maar het konflik met mekaar. Die taak is om beide takke in te smelt ontwikkel. In hierdie geval word dit aanbeveel om eers een van die takke saam te voeg ontwikkelen voeg dan saam ontwikkel na die oorblywende tak, die oplossing van konflikte in die oorblywende tak, en dan die laaste tak saam te voeg in ontwikkel. Tydens die konflikoplossingsfase moet u dalk die migrasielêer in die laaste tak regmaak sodat dit ooreenstem met die finale stortingsterrein, wat die resultate van die samesmeltings insluit.

Hoe om meer veranderinge in die databasisstruktuur veilig na 'n produksie-omgewing te ontplooi

Danksy die teenwoordigheid van 'n storting van die huidige databasisstruktuur in VCS, word dit moontlik om die produksiedatabasis na te gaan vir presiese voldoening aan die vereiste struktuur. Dit verseker dat al die veranderinge wat die ontwikkelaars beoog het, suksesvol na die produksiebasis oorgedra is.

As DDL in PostgreSQL is transaksionele, word dit aanbeveel om by die volgende ontplooiingsbevel te hou, sodat, in die geval van 'n onverwagte fout, jy "pynloos" kan uitvoer ROLLBACK:

1. Begin transaksie
2. Voer alle migrasies in 'n transaksie uit
3. In dieselfde transaksie, voer uit deployDump
4. Sonder om die transaksie te voltooi, voer uit verifyDump. As daar geen foute is nie, hardloop COMMIT. As daar foute is, hardloop ROLLBACK

Hierdie stappe kan maklik geïntegreer word in bestaande benaderings tot toepassing-ontplooiing, insluitend nul-stilstand.

Gevolgtrekking

Danksy die metodes wat hierbo beskryf word, is dit moontlik om maksimum prestasie uit "PHP + PostgreSQL"-projekte te druk, terwyl relatief min ontwikkelingsgerief opgeoffer word in vergelyking met die implementering van al die besigheidslogika in die hooftoepassingskode. Verder, dataverwerking in PL/pgSQL lyk dikwels meer deursigtig en vereis minder kode as dieselfde funksionaliteit wat in PHP geskryf is.

Bron: will.com