Tämän artikkelin tarkoituksena on käyttää esimerkkiä kirjastosta skeeman pitäjä Näytä työkalut, jotka voivat merkittävästi yksinkertaistaa tietokantojen kehittämistä PHP-projekteissa PostgreSQL DBMS:ää käyttäen.

Tämän artikkelin tiedot ovat ennen kaikkea hyödyllisiä kehittäjille, jotka haluavat hyödyntää PostgreSQL-ominaisuuksia parhaalla mahdollisella tavalla, mutta joilla on ongelmia tietokantaan sijoitetun liiketoimintalogiikan ylläpitämisessä.

Tässä artikkelissa ei kuvata liiketoimintalogiikan tietokantaan tallentamisen etuja tai haittoja. Oletetaan, että lukija on jo tehnyt valinnan.

Seuraavat kysymykset otetaan huomioon:

1. Missä muodossa tietokantarakennevedos tulee tallentaa versionhallintajärjestelmään (jäljempänä VCS)
2. Kuinka seurata muutoksia tietokantarakenteessa vedoksen tallentamisen jälkeen
3. Tietokannan rakenteen muutosten siirtäminen muihin ympäristöihin ilman ristiriitoja ja jättimäisiä siirtotiedostoja
4. Kuinka järjestää useiden kehittäjien projektien rinnakkaistyö
5. Kuinka ottaa turvallisesti käyttöön tietokantarakenteen muutoksia tuotantoympäristöön
   

   SchemaKeeper suunniteltu työskentelemään kielellä kirjoitettujen tallennettujen toimenpiteiden kanssa PL/pgSQL. Testausta muilla kielillä ei ole tehty, joten käyttö ei välttämättä ole yhtä tehokasta tai ei välttämättä ole mahdollista.

Tietokannan rakennevedosten tallentaminen VCS:ään

kirjasto skeeman pitäjä tarjoaa toiminnon saveDump, joka tallentaa kaikkien tietokannan objektien rakenteen erillisinä tekstitiedostoina. Tulos on tietokantarakenteen sisältävä hakemisto, joka on jaettu ryhmiteltyihin tiedostoihin, jotka voidaan helposti lisätä VCS:ään.

Katsotaanpa objektien muuntamista tietokannasta tiedostoiksi useiden esimerkkien avulla:

Objektityyppi
ohjelma
Nimi
Suhteellinen polku tiedostoon

pöytä
julkinen
tilit
./public/tables/accounts.txt

Tallennettu menettely
julkinen
auth (hash bigint)
./public/functions/auth(int8).sql

ajatus
varaus
tariffit
./booking/views/tariffs.txt

Tiedostojen sisältö on tekstimuotoinen esitys tietyn tietokantaobjektin rakenteesta. Esimerkiksi tallennettujen proseduurien kohdalla tiedoston sisältö on tallennetun proseduurin täydellinen määritelmä alkaen lohkosta CREATE OR REPLACE FUNCTION.

Kuten yllä olevasta taulukosta voidaan nähdä, tiedoston polku tallentaa tietoja objektin tyypistä, skeemasta ja nimestä. Tämä lähestymistapa helpottaa tietokannan muutosten vedos- ja kooditarkistuksen selailua.

laajentaminen .sql tiedostoille, joissa on tallennettu prosessin lähdekoodi, tämä valittiin siten, että IDE tarjoaa automaattisesti työkaluja vuorovaikutukseen tietokannan kanssa, kun tiedosto avataan.

Kuinka seurata muutoksia tietokantarakenteessa vedoksen tallentamisen jälkeen

Tallentamalla vedos nykyisestä tietokantarakenteesta VCS:ään, saamme mahdollisuuden tarkistaa, onko tietokantarakenteeseen tehty muutoksia vedoksen luomisen jälkeen. Kirjastossa skeeman pitäjä Tietokannan rakenteessa tapahtuvien muutosten havaitsemiseksi tarjotaan toiminto verifyDump, joka palauttaa tiedot eroista ilman sivuvaikutuksia.

Vaihtoehtoinen tapa tarkistaa on kutsua funktio uudelleen saveDump, joka määrittää saman hakemiston, ja tarkista muutokset VCS:stä. Koska kaikki tietokannan objektit tallennetaan erillisiin tiedostoihin, VCS näyttää vain muuttuneet objektit.
Tämän menetelmän suurin haittapuoli on tarve korvata tiedostoja muutosten näkemiseksi.

Tietokannan rakenteen muutosten siirtäminen muihin ympäristöihin ilman ristiriitoja ja jättimäisiä siirtotiedostoja

Toiminnan ansiosta deployDump Tallennettujen proseduurien lähdekoodia voidaan muokata täsmälleen samalla tavalla kuin tavallista sovelluksen lähdekoodia. Voit lisätä/poistaa uusia rivejä tallennettuun toimintokoodiin ja työntää muutokset välittömästi versionhallintaan tai luoda/poistaa tallennettuja proseduureja luomalla/poistamalla vastaavat tiedostot vedoshakemistosta.

Esimerkiksi luodaksesi uuden tallennetun proseduurin skeemaan public luo vain uusi tiedosto tunnisteella .sql hakemistossa public/functions, sijoita siihen tallennetun proseduurin lähdekoodi, lohko mukaan lukien CREATE OR REPLACE FUNCTIONja kutsu sitten funktiota deployDump. Tallennetun toimintosarjan muokkaaminen ja poistaminen tapahtuu samalla tavalla. Siten koodi menee sekä VCS:ään että tietokantaan samanaikaisesti.

Jos minkä tahansa tallennetun toimintosarjan lähdekoodissa ilmenee virhe tai tiedoston ja tallennetun toimintosarjan nimet poikkeavat toisistaan, deployDump epäonnistuu, näyttöön tulee virheteksti. Tallennettujen toimintojen yhteensopimattomuus vedoksen ja nykyisen tietokannan välillä on mahdotonta käytettäessä deployDump.

Kun luot uutta tallennettua toimintosarjaa, oikeaa tiedostonimeä ei tarvitse syöttää manuaalisesti. Riittää, että tiedostolla on tunniste .sql. Soiton jälkeen deployDump virheteksti sisältää oikean nimen, jota voidaan käyttää tiedoston nimeämiseen uudelleen.

deployDump voit muuttaa funktion tai palautustyypin parametreja ilman lisätoimia, kun taas klassisella lähestymistavalla sinun on pakko
suorita ensin DROP FUNCTION, ja vasta sitten CREATE OR REPLACE FUNCTION.

Valitettavasti on tilanteita, joissa deployDump muutoksia ei voi ottaa automaattisesti käyttöön. Jos esimerkiksi liipaisutoiminto, jota vähintään yksi liipaisin käyttää, poistetaan. Tällaiset tilanteet ratkaistaan ​​manuaalisesti siirtotiedostojen avulla.

Jos olet vastuussa muutosten siirtämisestä tallennettuihin toimenpiteisiin skeeman pitäjä, silloin siirtotiedostoja on käytettävä muiden rakenteen muutosten siirtämiseen. Esimerkiksi hyvä kirjasto siirtojen kanssa työskentelemiseen on oppi/muuttoliike.

Siirrot on tehtävä ennen käynnistämistä deployDump. Näin voit tehdä kaikki muutokset rakenteeseen ja ratkaista ongelmatilanteita niin, että muutokset tallennettuihin menettelyihin siirretään myöhemmin ilman ongelmia.

Siirtojen käsittelyä kuvataan yksityiskohtaisemmin seuraavissa osioissa.

Kuinka järjestää useiden kehittäjien projektien rinnakkaistyö

Tietokannan täydellistä alustamista varten on luotava skripti, jonka kehittäjä käynnistää työkoneellaan saattamalla paikallisen tietokannan rakenteen VCS:ään tallennetun dumpin mukaiseksi. Helpoin tapa on jakaa paikallisen tietokannan alustus kolmeen vaiheeseen:

1. Tuo perusrakenteinen tiedosto, jota kutsutaan nimellä esim. base.sql
2. Siirtojen soveltaminen
3. puhelu deployDump

base.sql on aloituspiste, jonka päällä siirtoja sovelletaan ja suoritetaan deployDumpToisin sanoen, base.sql + миграции + deployDump = актуальная структура БД. Voit luoda tällaisen tiedoston apuohjelman avulla pg_dump. Käytetty base.sql yksinomaan alustattaessa tietokantaa tyhjästä.

Kutsutaanko komentosarja tietokannan täydellistä alustusta varten refresh.sh. Työnkulku voi näyttää tältä:

1. Kehittäjä käynnistää ympäristössään refresh.sh ja saa nykyisen tietokantarakenteen
2. Kehittäjä aloittaa työskentelyn käsillä olevan tehtävän parissa ja muokkaa paikallista tietokantaa vastaamaan uuden toiminnallisuuden tarpeita (ALTER TABLE ... ADD COLUMN ja niin edelleen)
3. Tehtävän suorittamisen jälkeen kehittäjä kutsuu funktiota saveDumpVCS:n tietokantaan tehtyjen muutosten tekemiseen
4. Kehittäjän uudelleenkäynnistys refresh.sh, sitten verifyDumpjoka näyttää nyt luettelon muutoksista, jotka sisällytetään siirtoon
5. Kehittäjä siirtää kaikki rakennemuutokset siirtotiedostoon ja suorittaa sen uudelleen refresh.sh и verifyDump, ja jos siirto on käännetty oikein, verifyDump ei näytä eroja paikallisen tietokannan ja tallennetun vedoksen välillä

Yllä kuvattu prosessi on yhteensopiva gitflow-periaatteiden kanssa. Jokainen VCS:n haara sisältää oman versionsa kaatopaikasta, ja haaroja yhdistettäessä kaatopaikat yhdistetään. Useimmissa tapauksissa yhdistämisen jälkeen ei tarvitse tehdä lisätoimenpiteitä, mutta jos muutoksia on tehty eri haaroihin, esimerkiksi samaan taulukkoon, voi syntyä ristiriita.

Tarkastellaanpa konfliktitilannetta esimerkin avulla: siellä on haara kehittää, josta haarautuu kaksi haaraa: feature1 и feature2, joiden kanssa ei ole ristiriitoja kehittää, mutta heillä on ristiriitoja keskenään. Tehtävänä on yhdistää molemmat haarat kehittää. Tässä tapauksessa on suositeltavaa yhdistää ensin yksi haarasta kehittääja sitten yhdistää kehittää jäljellä olevaan haaraan ratkaisemalla ristiriidat jäljellä olevassa haarassa ja yhdistämällä sitten viimeisen haaran kehittää. Ristiriitojen ratkaisuvaiheessa saatat joutua korjaamaan viimeisen haaran siirtotiedoston niin, että se vastaa lopullista vedostiedostoa, joka sisältää yhdistämisten tulokset.

Kuinka ottaa turvallisesti käyttöön tietokantarakenteen muutoksia tuotantoympäristöön

VCS:n nykyisen tietokantarakenteen kaatopaikan ansiosta on mahdollista tarkistaa tuotantotietokannan tarkka vaatimustenmukaisuus vaaditun rakenteen kanssa. Näin varmistetaan, että kaikki kehittäjien suunnittelemat muutokset siirrettiin onnistuneesti tuotantopohjaan.

Kuin DDL PostgreSQL:ssä on kaupallinen, on suositeltavaa noudattaa seuraavaa käyttöönottojärjestystä, jotta odottamattoman virheen sattuessa voit suorittaa "kivuttomasti" ROLLBACK:

1. Aloita kauppa
2. Suorita kaikki siirrot tapahtumassa
3. Suorita samassa tapahtumassa deployDump
4. Suorita suorittamatta tapahtumaa verifyDump. Jos virheitä ei ole, suorita COMMIT. Jos on virheitä, suorita ROLLBACK

Nämä vaiheet voidaan helposti integroida olemassa oleviin sovellusten käyttöönottomenetelmiin, mukaan lukien nollakatkosaika.

Johtopäätös

Yllä kuvattujen menetelmien ansiosta on mahdollista puristaa maksimaalinen suorituskyky "PHP + PostgreSQL" -projekteista uhraten suhteellisen vähän kehitysmukavuudesta verrattuna kaiken liiketoimintalogiikan toteuttamiseen pääsovelluskoodissa. Lisäksi tietojenkäsittely sisään PL/pgSQL näyttää usein läpinäkyvämmältä ja vaatii vähemmän koodia kuin samat toiminnot kirjoitettuna PHP:llä.

Lähde: will.com