Het doel van dit artikel is om het voorbeeld van een bibliotheek te gebruiken schema-bewaarder toon tools die het proces van het ontwikkelen van databases binnen PHP-projecten met behulp van PostgreSQL DBMS aanzienlijk kunnen vereenvoudigen.

De informatie uit dit artikel zal in de eerste plaats nuttig zijn voor ontwikkelaars die het maximale uit de mogelijkheden van PostgreSQL willen halen, maar geconfronteerd worden met problemen bij het onderhouden van de bedrijfslogica die in de database is geplaatst.

Het artikel beschrijft niet de voor- of nadelen van het opslaan van bedrijfslogica in een database. Er wordt aangenomen dat de keuze al door de lezer is gemaakt.

De volgende vragen zullen worden overwogen:

In welke vorm moet een databasestructuurdump worden opgeslagen in een versiebeheersysteem (hierna VCS genoemd)
Hoe u wijzigingen in de databasestructuur kunt volgen na het opslaan van een dump
Hoe u wijzigingen in de databasestructuur kunt overbrengen naar andere omgevingen zonder conflicten en gigantische migratiebestanden
Hoe het proces van parallel werken aan een project door meerdere ontwikkelaars te organiseren
Hoe u veilig meer wijzigingen in de databasestructuur kunt implementeren in een productieomgeving

SchemaKeeper ontworpen voor het werken met opgeslagen procedures die in de taal zijn geschreven PL / pgSQL. Testen met andere talen zijn niet uitgevoerd, dus gebruik is mogelijk niet zo effectief of mogelijk niet mogelijk.

Hoe een databasestructuurdump op te slaan in VCS

bibliotheek schema-bewaarder biedt een functie saveDump, waarmee de structuur van alle objecten uit de database als afzonderlijke tekstbestanden wordt opgeslagen. De uitvoer is een map met de databasestructuur, onderverdeeld in gegroepeerde bestanden die eenvoudig aan VCS kunnen worden toegevoegd.

Laten we eens kijken naar het converteren van objecten uit een database naar bestanden met behulp van verschillende voorbeelden:

Object type
Het schema
Naam
Relatief pad naar bestand

tafel
publiek
rekeningen
./public/tables/accounts.txt

Opgeslagen procedure
publiek
auth(hash bigint)
./public/functions/auth(int8).sql

idee
boeken
tarieven
./booking/views/tariffs.txt

De inhoud van de bestanden is een tekstuele weergave van de structuur van een specifiek databaseobject. Voor opgeslagen procedures zal de inhoud van het bestand bijvoorbeeld de volledige definitie van de opgeslagen procedure zijn, te beginnen met het blok CREATE OR REPLACE FUNCTION.

Zoals uit de bovenstaande tabel blijkt, slaat het pad naar het bestand informatie op over het type, het schema en de naam van het object. Deze aanpak maakt het gemakkelijker om door de dump en codebeoordeling van wijzigingen in de database te navigeren.

uitbreiding .sql voor bestanden met opgeslagen procedurebroncode is dit zo geselecteerd dat de IDE automatisch hulpmiddelen biedt voor interactie met de database wanneer het bestand wordt geopend.

Hoe u wijzigingen in de databasestructuur kunt volgen na het opslaan van een dump

Door een dump van de huidige databasestructuur in VCS op te slaan, krijgen we de mogelijkheid om te controleren of er wijzigingen zijn aangebracht in de databasestructuur nadat de dump is gemaakt. In de bibliotheek schema-bewaarder om veranderingen in de databasestructuur te detecteren, is er een functie voorzien verifyDump, dat informatie retourneert over de verschillen zonder bijwerkingen.

Een alternatieve manier om dit te controleren is door de functie opnieuw aan te roepen saveDump, geef dezelfde map op en controleer VCS op wijzigingen. Omdat alle objecten uit de database in aparte bestanden worden opgeslagen, toont VCS alleen gewijzigde objecten.
Het grootste nadeel van deze methode is de noodzaak om bestanden te overschrijven om de wijzigingen te zien.

Hoe u wijzigingen in de databasestructuur kunt overbrengen naar andere omgevingen zonder conflicten en gigantische migratiebestanden

Dankzij de functie deployDump De broncode van opgeslagen procedures kan op precies dezelfde manier worden bewerkt als de reguliere applicatiebroncode. U kunt nieuwe regels in de opgeslagen procedurecode toevoegen/verwijderen en wijzigingen onmiddellijk naar versiebeheer pushen, of opgeslagen procedures maken/verwijderen door de overeenkomstige bestanden in de dumpmap te maken/verwijderen.

Bijvoorbeeld om een nieuwe opgeslagen procedure in een schema te maken public maak gewoon een nieuw bestand met de extensie .sql in de map public/functions, plaats daarin de broncode van de opgeslagen procedure, inclusief het blok CREATE OR REPLACE FUNCTIONen roep vervolgens de functie aan deployDump. Het wijzigen en verwijderen van een opgeslagen procedure gebeurt op dezelfde manier. De code gaat dus tegelijkertijd naar zowel de VCS als de database.

Als er een fout optreedt in de broncode van een opgeslagen procedure, of als er een discrepantie bestaat tussen de namen van het bestand en de opgeslagen procedure, dan deployDump mislukt en geeft een fouttekst weer. Mismatch van opgeslagen procedures tussen de dump en de huidige database is onmogelijk bij gebruik deployDump.

Wanneer u een nieuwe opgeslagen procedure maakt, hoeft u niet handmatig de juiste bestandsnaam in te voeren. Het is voldoende dat het bestand de extensie heeft .sql. Na de oproep deployDump de fouttekst bevat de juiste naam, die kan worden gebruikt om het bestand te hernoemen.

deployDump Hiermee kunt u de parameters van een functie of retourtype wijzigen zonder aanvullende acties, terwijl u dat met de klassieke aanpak wel zou moeten doen
eerst uitvoeren DROP FUNCTION, en alleen dan CREATE OR REPLACE FUNCTION.

Helaas zijn er enkele situaties waarin deployDump kan wijzigingen niet automatisch toepassen. Bijvoorbeeld als een triggerfunctie die door ten minste één trigger wordt gebruikt, wordt verwijderd. Dergelijke situaties worden handmatig opgelost met behulp van migratiebestanden.

Als u verantwoordelijk bent voor het migreren van wijzigingen in opgeslagen procedures schema-bewaarder, dan moeten migratiebestanden worden gebruikt om andere wijzigingen in de structuur over te dragen. Een goede bibliotheek om met migraties te werken is bijvoorbeeld doctrine/migraties.

Migraties moeten vóór de lancering worden toegepast deployDump. Hiermee kunt u alle wijzigingen in de structuur aanbrengen en probleemsituaties oplossen, zodat wijzigingen in opgeslagen procedures vervolgens zonder problemen worden overgedragen.

Het werken met migraties wordt in de volgende paragrafen gedetailleerder beschreven.

Hoe het proces van parallel werken aan een project door meerdere ontwikkelaars te organiseren

Het is noodzakelijk om een script te maken voor de volledige initialisatie van de database, dat door de ontwikkelaar op zijn werkcomputer wordt gestart, waardoor de structuur van de lokale database in overeenstemming wordt gebracht met de dump die is opgeslagen in VCS. De eenvoudigste manier is om de initialisatie van de lokale database in 3 stappen te verdelen:

Importeer een bestand met een basisstructuur die b.v. base.sql
Migraties toepassen
telefoontje deployDump

base.sql is het startpunt waarop migraties worden toegepast en uitgevoerd deployDumpDat wil zeggen, base.sql + миграции + deployDump = актуальная структура БД. U kunt een dergelijk bestand maken met behulp van het hulpprogramma pg_dump. gebruikt base.sql uitsluitend bij het helemaal opnieuw initialiseren van de database.

Laten we het script aanroepen voor volledige database-initialisatie refresh.sh. De werkstroom kan er als volgt uitzien:

De ontwikkelaar lanceert in zijn omgeving refresh.sh en haalt de huidige databasestructuur op
De ontwikkelaar begint aan de uit te voeren taak en past de lokale database aan om aan de behoeften van de nieuwe functionaliteit te voldoen (ALTER TABLE ... ADD COLUMN enz)
Nadat de taak is voltooid, roept de ontwikkelaar de functie aan saveDumpom wijzigingen in de database in VCS vast te leggen
Herlancering van de ontwikkelaar refresh.sh, we zweren het verifyDumpwaarin nu een lijst met wijzigingen wordt weergegeven die in de migratie moeten worden opgenomen
De ontwikkelaar brengt alle structuurwijzigingen over naar het migratiebestand en voert het opnieuw uit refresh.sh и verifyDump, en, als de migratie correct is samengesteld, verifyDump zal geen verschillen vertonen tussen de lokale database en de opgeslagen dump

Het hierboven beschreven proces is compatibel met gitflow-principes. Elke vertakking in de VCS zal zijn eigen versie van de dump bevatten, en bij het samenvoegen van vertakkingen zullen de dumps worden samengevoegd. In de meeste gevallen hoeft er na een samenvoeging geen extra actie te worden ondernomen, maar als er in verschillende branches wijzigingen worden aangebracht, bijvoorbeeld aan dezelfde tabel, kan er een conflict ontstaan.

Laten we een conflictsituatie bekijken aan de hand van een voorbeeld: er is een vertakking ontwikkelen, waaruit twee takken aftakken: feature1 и feature2, waar geen conflicten mee bestaan ontwikkelen, maar hebben conflicten met elkaar. De taak is om beide takken samen te voegen tot ontwikkelen. In dit geval wordt aanbevolen om eerst een van de vertakkingen samen te voegen ontwikkelenen dan samenvoegen ontwikkelen naar de resterende tak, conflicten in de resterende tak oplossen en vervolgens de laatste tak samenvoegen ontwikkelen. Tijdens de conflictoplossingsfase moet u mogelijk het migratiebestand in de laatste vertakking repareren, zodat het overeenkomt met de uiteindelijke dump, die de resultaten van de samenvoegingen bevat.

Hoe u veilig meer wijzigingen in de databasestructuur kunt implementeren in een productieomgeving

Dankzij de aanwezigheid van een dump van de huidige databasestructuur in VCS wordt het mogelijk om de productiedatabase te controleren op exacte overeenstemming met de vereiste structuur. Dit zorgt ervoor dat alle veranderingen die de ontwikkelaars voor ogen hadden, met succes werden overgebracht naar de productiebasis.

Als DDL in PostgreSQL is transactioneel, wordt aanbevolen om de volgende implementatievolgorde aan te houden, zodat u in geval van een onverwachte fout “pijnloos” kunt uitvoeren ROLLBACK:

Transactie starten
Voer alle migraties in één transactie uit
Voer in dezelfde transactie uit deployDump
Voer de transactie uit zonder de transactie te voltooien verifyDump. Als er geen fouten zijn, voer dan uit COMMIT. Als er fouten zijn, voer dan uit ROLLBACK

Deze stappen kunnen eenvoudig worden geïntegreerd in bestaande benaderingen van applicatie-implementatie, inclusief zero-downtime.

Conclusie

Dankzij de hierboven beschreven methoden is het mogelijk om maximale prestaties uit “PHP + PostgreSQL”-projecten te halen, terwijl er relatief weinig ontwikkelingsgemak wordt opgeofferd vergeleken met het implementeren van alle bedrijfslogica in de hoofdapplicatiecode. Bovendien is de gegevensverwerking in PL / pgSQL ziet er vaak transparanter uit en vereist minder code dan dezelfde functionaliteit geschreven in PHP.

Bron: www.habr.com

Bedrijfslogica in de database met behulp van SchemaKeeper