Bedriuwslogika yn 'e database mei SchemaKeeper

It doel fan dit artikel is om it foarbyld fan in bibleteek te brûken skema-keeper lit ark sjen dy't it proses fan it ûntwikkeljen fan databases binnen PHP-projekten signifikant kinne ferienfâldigje mei de PostgreSQL DBMS.

De ynformaasje fan dit artikel sil, yn it foarste plak, nuttich wêze foar ûntwikkelders dy't it measte wolle meitsje fan PostgreSQL-mooglikheden, mar wurde konfrontearre mei problemen mei it behâld fan bedriuwslogika pleatst yn 'e database.

Dit artikel sil de foardielen of neidielen net beskriuwe fan it opslaan fan saaklike logika yn in database. Der wurdt fan útgien dat de kar al makke is troch de lêzer.

De folgjende fragen sille wurde beskôge:

  1. Yn hokker foarm moat in databankstruktuerdump wurde opslein yn in ferzjekontrôlesysteem (hjirnei oantsjutten as VCS)
  2. Hoe kinne jo feroaringen yn 'e databankstruktuer folgje nei it bewarjen fan in dump
  3. Hoe kinne jo wizigingen yn 'e databankstruktuer oerdrage nei oare omjouwings sûnder konflikten en gigantyske migraasjebestannen
  4. Hoe te organisearjen it proses fan parallel wurk oan in projekt troch ferskate ûntwikkelders
  5. Hoe kinne jo mear wizigingen yn 'e databankstruktuer feilich ynsette yn in produksjeomjouwing

    SchemaKeeper ûntworpen om te wurkjen mei bewarre prosedueres skreaun yn 'e taal PL/pgSQL. Testen mei oare talen is net útfierd, dus it gebrûk is miskien net sa effektyf of miskien net mooglik.

Hoe te bewarjen in databank struktuer dump yn VCS

Bibleteek skema-keeper jout in funksje saveDump, dy't de struktuer fan alle objekten út 'e databank bewarret as aparte tekstbestannen. De útfier is in map mei de databankstruktuer, ferdield yn groepeare bestannen dy't maklik kinne wurde tafoege oan VCS.

Litte wy sjen nei it konvertearjen fan objekten út in databank yn bestannen mei ferskate foarbylden:

Objekt type
De regeling
Titel
Relatyf paad nei triem

tabel
iepenbier
akkounts
./public/tables/accounts.txt

Opslein proseduere
iepenbier
auth (hash bigint)
./public/functions/auth(int8).sql

Ynlieding
registrearre
tariven
./booking/views/tariffs.txt

De ynhâld fan 'e bestannen binne in tekstuele foarstelling fan 'e struktuer fan in spesifyk databankobjekt. Bygelyks, foar bewarre prosedueres sil de ynhâld fan it bestân de folsleine definysje wêze fan 'e bewarre proseduere, begjinnend mei it blok CREATE OR REPLACE FUNCTION.

As kin sjoen wurde út de tabel hjirboppe, it paad nei de triem bewarret ynformaasje oer it type, skema en namme fan it objekt. Dizze oanpak makket it makliker om te navigearjen troch de dump- en koadebeoardieling fan wizigingen yn 'e databank.

extension .sql foar triemmen mei bewarre proseduere boarnekoade, dit waard selektearre sadat de IDE automatysk jout ark foar ynteraksje mei de databank as de triem wurdt iepene.

Hoe kinne jo feroaringen yn 'e databankstruktuer folgje nei it bewarjen fan in dump

Troch it bewarjen fan in dump fan de hjoeddeiske databank struktuer yn VCS, wy krije de mooglikheid om te kontrolearjen oft feroarings waarden makke oan de databank struktuer neidat de dump waard makke. Yn biblioteek skema-keeper om feroarings yn 'e databankstruktuer te detektearjen, wurdt in funksje levere verifyDump, dy't ynformaasje jout oer de ferskillen sûnder side-effekten.

In alternative manier om te kontrolearjen is om de funksje opnij oan te roppen saveDump, spesifisearje deselde map, en kontrolearje yn VCS foar feroarings. Sûnt alle objekten út de databank wurde bewarre yn aparte triemmen, sil VCS allinne sjen litte feroare objekten.
It wichtichste neidiel fan dizze metoade is de needsaak om bestannen te oerskriuwen om de wizigingen te sjen.

Hoe kinne jo wizigingen yn 'e databankstruktuer oerdrage nei oare omjouwings sûnder konflikten en gigantyske migraasjebestannen

Mei tank oan de funksje deployDump De boarnekoade fan opsleine prosedueres kin op krekt deselde wize bewurke wurde as de gewoane applikaasjeboarnekoade. Jo kinne tafoegje / wiskje nije rigels yn bewarre proseduere koade en fuortendaliks triuwe feroarings oan ferzje kontrôle, of meitsje / wiskje bewarre prosedueres troch it meitsjen / wiskjen fan de oerienkommende triemmen yn de dump triemtafel.

Bygelyks om in nije opsleine proseduere te meitsjen yn in skema public meitsje gewoan in nij bestân mei de tafoeging .sql yn de map public/functions, pleats de boarnekoade fan 'e opsleine proseduere dêryn, ynklusyf it blok CREATE OR REPLACE FUNCTION, rop dan de funksje op deployDump. It wizigjen en wiskjen fan in bewarre proseduere bart op deselde wize. Sa giet de koade tagelyk yn sawol de VCS as de databank.

As in flater ferskynt yn 'e boarnekoade fan in opsleine proseduere, of in diskrepânsje tusken de nammen fan it bestân en de bewarre proseduere, dan deployDump sil mislearje, displaying flater tekst. Mismatch fan bewarre prosedueres tusken de dump en de hjoeddeiske databank is ûnmooglik by it brûken deployDump.

By it meitsjen fan in nije opsleine proseduere is it net nedich om de juste triemnamme manuell yn te fieren. It is genôch foar it bestân om de tafoeging te hawwen .sql. Nei de oprop deployDump de flatertekst sil de juste namme befetsje, dy't brûkt wurde kin om it bestân omneame.

deployDump kinne jo de parameters fan in funksje of returntype feroarje sûnder ekstra aksjes, wylst jo mei de klassike oanpak moatte
earst útfiere DROP FUNCTION, en pas dan CREATE OR REPLACE FUNCTION.

Spitigernôch, der binne guon situaasjes dêr't deployDump kin net automatysk wizigingen tapasse. Bygelyks, as in triggerfunksje dy't brûkt wurdt troch op syn minst ien trigger wurdt fuortsmiten. Sokke situaasjes wurde mei de hân oplost mei migraasjebestannen.

As jo ​​​​ferantwurdlik binne foar it migrearjen fan feroaringen nei bewarre prosedueres skema-keeper, dan moatte migraasjebestannen brûkt wurde om oare wizigingen yn 'e struktuer oer te dragen. Bygelyks, in goede bibleteek foar wurkjen mei migraasjes is lear / migraasjes.

Migraasjes moatte wurde tapast foar lansearring deployDump. Hjirmei kinne jo alle wizigingen yn 'e struktuer meitsje en problematyske situaasjes oplosse, sadat feroaringen yn opsleine prosedueres dêrnei sûnder problemen wurde oerdroegen.

It wurkjen mei migraasjes sil yn 'e folgjende seksjes yn mear detail beskreaun wurde.

Hoe te organisearjen it proses fan parallel wurk oan in projekt troch ferskate ûntwikkelders

It is needsaaklik om in skript te meitsjen foar de folsleine inisjalisaasje fan 'e databank, dy't sil wurde lansearre troch de ûntwikkelder op syn wurkmasine, wêrtroch de struktuer fan' e lokale databank yn oerienstimming bringt mei de dump bewarre yn VCS. De maklikste manier is om de inisjalisaasje fan 'e lokale databank te ferdielen yn 3 stappen:

  1. Ymportearje in bestân mei in basisstruktuer dy't bgl. base.sql
  2. It tapassen fan migraasjes
  3. Challenge deployDump

base.sql is it begjinpunt wêrop migraasjes wurde tapast en útfierd deployDump, dat is base.sql + миграции + deployDump = актуальная структура БД. Jo kinne sa'n bestân oanmeitsje mei it hulpprogramma pg_dump. Used base.sql eksklusyf by it inisjalisearjen fan de databank fanôf it begjin.

Litte wy it skript neame foar folsleine inisjalisaasje fan databases refresh.sh. De workflow kin der sa útsjen:

  1. De ûntwikkelder lansearret yn syn omjouwing refresh.sh en krijt de hjoeddeistige databankstruktuer
  2. De ûntwikkelder begjint te wurkjen oan 'e taak by de hân, en feroaret de lokale databank om te foldwaan oan' e behoeften fan 'e nije funksjonaliteit (ALTER TABLE ... ADD COLUMN ensfh)
  3. Nei it foltôgjen fan de taak ropt de ûntwikkelder de funksje op saveDumpom wizigingen te meitsjen oan 'e databank yn VCS
  4. Developer relaunch refresh.sh, dan verifyDumpdy't no in list toant mei wizigingen dy't moatte wurde opnommen yn 'e migraasje
  5. De ûntwikkelder draacht alle struktuerwizigingen oer nei it migraasjebestân, rint wer refresh.sh и verifyDump, en, as de migraasje goed kompilearre is, verifyDump sil gjin ferskillen sjen litte tusken de lokale databank en de bewarre dump

It hjirboppe beskreaune proses is kompatibel mei gitflow-prinsipes. Elke tûke yn 'e VCS sil in eigen ferzje fan' e dump befetsje, en by it fusearjen fan tûken sille de dumps wurde gearfoege. Yn 'e measte gefallen hoecht gjin ekstra aksje te nimmen nei in fúzje, mar as feroaringen makke binne yn ferskate tûken, bygelyks oan deselde tabel, kin in konflikt ûntstean.

Litte wy in konfliktsituaasje beskôgje mei in foarbyld: d'r is in branch ûntwikkelje, wêrfan twa tûken ôfwikselje: funksje1 и funksje2, dy't hawwe gjin konflikten mei ûntwikkelje, mar hawwe konflikten mei elkoar. De taak is om beide tûken yn te fusearjen ûntwikkelje. Foar dit gefal is it oan te rieden om earst ien fan 'e tûken yn te fusearjen ûntwikkeljeen dan gearfoegje ûntwikkelje nei de oerbleaune tûke, konflikten yn 'e oerbleaune tûke oplosse, en dan de lêste tûke gearfoegje yn ûntwikkelje. Tidens de faze fan konfliktoplossing moatte jo miskien it migraasjebestân yn 'e lêste tûke reparearje sadat it oerienkomt mei de definitive dump, dy't de resultaten fan' e fúzjes omfettet.

Hoe kinne jo mear wizigingen yn 'e databankstruktuer feilich ynsette yn in produksjeomjouwing

Mei tank oan de oanwêzigens fan in dump fan 'e hjoeddeistige databankstruktuer yn VCS, wurdt it mooglik om de produksjedatabase te kontrolearjen foar krekte konformiteit mei de fereaske struktuer. Dit soarget derfoar dat alle wizigingen dy't de ûntwikkelders bedoeld hawwe, mei sukses oerdroegen oan 'e produksjebasis.

sûnt DDL yn PostgreSQL is transaksjoneel, is it oan te rieden om de folgjende ynsetopdracht te folgjen, sadat jo yn it gefal fan in ûnferwachte flater "pynlik" kinne útfiere ROLLBACK:

  1. Start transaksje
  2. Fier alle migraasjes yn in transaksje
  3. Yn deselde transaksje, útfiere deployDump
  4. Sûnder de transaksje te foltôgjen, útfiere verifyDump. As d'r gjin flaters binne, rinne dan COMMIT. As d'r flaters binne, rinne dan ROLLBACK

Dizze stappen kinne maklik wurde yntegrearre yn besteande oanpakken foar ynset fan applikaasjes, ynklusyf nul-downtime.

konklúzje

Mei tank oan de hjirboppe beskreaune metoaden is it mooglik om maksimale prestaasjes út "PHP + PostgreSQL" projekten te squeeze, wylst relatyf lyts ûntwikkelingsgemak opofferje yn ferliking mei it útfieren fan alle saaklike logika yn 'e haadapplikaasjekoade. Boppedat, gegevens ferwurking yn PL/pgSQL sjocht faaks transparanter en fereasket minder koade as deselde funksjonaliteit skreaun yn PHP.

Boarne: www.habr.com

Add a comment