ProHoster > Blog > Administrimi > Logjika e biznesit në bazën e të dhënave me ndihmën e SchemaKeeper

Logjika e biznesit në bazën e të dhënave me ndihmën e SchemaKeeper

Qëllimi i këtij artikulli është të ilustrojë me shembuj nga biblioteka schema-keeper mjetet që lejojnë të ndihmojnë ndjeshëm procesin e zhvillimit të bazave të dhënash në projektet PHP që përdorin DBMS PostgreSQL.

Informacioni në këtë artikull do të jetë sidomos i dobishëm për zhvilluesit që duan të shfrytëzojnë në maksimum mundësitë e PostgreSQL, por përballen me probleme në mbështetje të logjikës së biznesit të përfshirë në DB.

Artikulli nuk do të përshkruajë përparësitë ose disavantazhet e ruajtjes së logjikës së biznesit në bazën e të dhënave. Pranohet që zgjedhja tashmë është bërë nga lexuesi.

Do të shqyrtohen çështjet e mëposhtme:

  1. Si të ruhet dumpi i strukturës së DB në sistemin e kontrollit të versioneve (VCS)
  2. Si të gjurmohen ndryshimet në strukturën e DB pas ruajtjes së dumpit
  3. Si të transferohen ndryshimet në strukturën e DB në mjedise të tjera pa konflikte dhe skedarë migrimi gjigantë
  4. Si të organizohet procesi i punës paralele të disa zhvilluesve në projekt
  5. Si të depozitohen në mënyrë të sigurtë një numër të madh të ndryshimeve në strukturën e DB në mjedisin production

    SchemaKeeper është krijuar për të punuar me procedurat e ruajtura të shkruara në gjuhën PL/pgSQL. Testimi me gjuhë të tjera nuk është kryer, kështu që përdorimi mund të mos jetë aq efikas, ose i pamundur.

Si të ruhet dumpi i strukturës së DB në VCS

Biblioteka schema-keeper ofron funksionin saveDump, i cili ruan strukturën e të gjithë objekteve nga DB si skedarë të veçantë tekstualë. Në fund krijohet një direktori që përmban strukturën e DB, e cila është e ndarë në skedarë të grupuar që mund të shtohen lehtësisht në VCS.

Le të shqyrtojmë transformimin e objekteve nga DB në skedarë në disa shembuj:

Tipi i objektit
Skema
Emri
Rruga relative deri në skedar

Tabela
publike
accounts
./public/tables/accounts.txt

Procedura e ruajtur
publike
auth(hash bigint)
./public/functions/auth(int8).sql

Prezantimi
booking
tariffs
./booking/views/tariffs.txt

Përmbajtja e skedarëve është një përfaqësim tekstual i strukturës së objektit specifik DB. Për shembull, për procedurat e ruajtura, përmbajtja e skedarit do të jetë definimi i plotë i procedurës së ruajtur, duke filluar nga blloku CREATE OR REPLACE FUNCTION.

Siç duket nga tabela më sipër, rruga e skedarit përmban informacion mbi tipin, skemën dhe emrin e objektit. Ky qasje lehtëson navigimin në dump dhe rishikimin e ndryshimeve në DB.

Zgjerimi .sql për skedarët me kodin burimor të procedurave të ruajtura u zgjodh për të mundësuar që IDE të ofronin automatikisht mjete për ndërveprimin me DB kur hapet skedari.

Si të gjurmohen ndryshimet në strukturën e DB pas ruajtjes së dumpit

Duke ruajtur dumpin e strukturës aktuale të DB në VCS, ne krijojmë mundësinë për të verifikuar nëse janë bërë ndryshime në strukturën e bazës pas krijimit të dumpit. Në bibliotekë schema-keeper për identifikimin e ndryshimeve në strukturën e DB është parashikuar funksioni verifyDump, i cili pa efekte anësore kthen informacion mbi ndryshimet.

NjĂ« mĂ«nyrĂ« alternative pĂ«r kontrollin — tĂ« thĂ«rrasĂ«sh pĂ«rsĂ«ri funksionin saveDump, duke caktuar tĂ« njĂ«jtĂ«n direktori dhe tĂ« kontrollosh nĂ« VCS praninĂ« e ndryshimeve. Duke qenĂ« se tĂ« gjithĂ« objektet nga DB janĂ« ruajtur nĂ« skedarĂ« tĂ« veçantĂ«, VCS do tĂ« tregojĂ« vetĂ«m objektet e ndryshuara.
Pika kryesore negative e këtij mënyre është nevoja për të rishkruar skedarët për të parë ndryshimet.

Si të transferohen ndryshimet në strukturën e DB në mjedise të tjera pa konflikte dhe skedarë migrimi gjigantë

Falë funksionit deployDump kodin burimor të procedurave të ruajtura mund të modifikohet në mënyrë krejtësisht të ngjashme me kodin burimor të aplikacionit. Mund të shtoni/fshini linja të reja në kodin e procedurave të ruajtura dhe menjëherë të dërgoni ndryshimet në sistemin e kontrollit të versioneve, ose të krijoni/fshini procedura të ruajtura duke krijuar/fshirë skedarët përkatës në direktorinë e dumpit.

Për shembull, për të krijuar një procedurë të re të ruajtur në skemën publike mjafton të krijosh një skedar të ri me zgjerim .sql në direktorinë public/functions, të vendosësh në të kodin burimor të procedurës së ruajtur, duke përfshirë bllokun CREATE OR REPLACE FUNCTION, pastaj të thërrasësh funksionin deployDump. Po ashtu ndodhin ndryshimet dhe fshirjet e procedurave të ruajtura. Në këtë mënyrë, kodi i njëherësh depersonalizohet në VCS, po ashtu dhe në bazën e të dhënave.

Nëse në kodin burimor të ndonjë procedure të ruajtur shfaqet një gabim, ose moskonsistencë midis emrave të skedarit dhe procedurës së ruajtur, atëherë deployDump nuk do të ekzekutohet, duke shfaqur tekstin e gabimit. Moskonsistenca e procedurave të ruajtura midis dumpit dhe DB aktuale është e pamundur në përdorimin e deployDump.

Kur krijoni një procedurë të re të ruajtur, nuk është e nevojshme të futni manualisht emrin e saktë të skedarit. Mjafton që skedari të ketë zgjerimin .sql. Pas thirrjes së deployDump teksti i gabimit do të përmbajë emrin e saktë, i cili mund të përdoret për të riemëruar skedarin.

deployDump lejon të ndryshosh parametrat e funksionit ose tipin e kthimit pa veprime të tjera, ndërsa në qasjen klasike do të duhej të
fillimisht të ekzekutoje DROP FUNCTION, dhe vetëm pastaj CREATE OR REPLACE FUNCTION.

Fatkeqësisht, ekzistojnë disa situata ku deployDump nuk mund të zbatojë automatikisht ndryshimet. Për shembull, nëse hiqet një funksion ndikues që përdoret nga të paktën një ndikues tjetër. Të tilla situata zgjidhen manualisht duke përdorur skedarë migrimi.

Nëse për transferimin e ndryshimeve në procedurat e ruajtura është përgjegjës vetë schema-keeper, atëherë për transferimin e ndryshimeve të tjera në strukturë është e nevojshme të përdoren skedarë migrimi. Për shembull, një bibliotekë e mirë për të punuar me migrimet është doctrine/migrations.

Migrimet duhet të aplikohen para nisjes deployDump. Kjo lejon bëj të gjitha ndryshimet në strukturë dhe të zgjidh problemet, në mënyrë që ndryshimet në procedurat e ruajtura më pas të transferohen pa probleme.

Më hollësisht, puna me migrimet do të përshkruhet në kapitujt e ardhshëm.

Si të organizohet procesi i punës paralele të disa zhvilluesve në projekt

Duhet të krijohet një skript për inicializimin e plotë të DB, i cili do të aktivizohet nga zhvilluesi në makinë e tij të punës, duke sjellë strukturën e DB lokale në përputhje me dump-in e ruajtur në VCS. Më së lehti është të ndajmë inicializimin e DB lokale në 3 hapa:

  1. Importimi i skedarit me strukturën bazë, i cili do të quhet, për shembull, base.sql
  2. Zbatimi i migrimeve
  3. Thirrja deployDump

base.sql — kjo Ă«shtĂ« pika e nisjes, mbi tĂ« cilĂ«n zbatohen migrimet dhe ekzekutohet deployDump, qĂ« do tĂ« thotĂ« base.sql + migrimet + deployDump = struktura aktuale e DB. NjĂ« skedar tĂ« tillĂ« mund ta formoni pĂ«rmes utilitarit pg_dump. PĂ«rdoret base.sql pĂ«r herĂ« tĂ« parĂ« kur inicializohet baza e tĂ« dhĂ«nave nga zero.

Ta quajmë skriptin për inicializimin e plotë të DB refresh.sh. Procesi i punës mund të duket si më poshtë:

  1. Zhvilluesi aktivizon në mjedisin e tij refresh.sh dhe merr strukturën aktuale të DB
  2. Zhvilluesi fillon të punojë mbi detyrën e dhënë, duke modifikuar DB lokale sipas nevojave të funksionalitetit të ri (ALTER TABLE ... ADD COLUMN etj.)
  3. Pas përfundimit të detyrës, zhvilluesi thërret funksionin saveDump, për të regjistruar në VCS ndryshimet e bëra në DB
  4. Zhvilluesi ekzekuton sërish refresh.sh, pastaj verifyDump, i cili tani tregon një listë ndryshimesh për përfshirje në migrim
  5. Zhvilluesi transferon të gjitha ndryshimet e strukturës në skedarin e migrimit, ekzekuton sërish refresh.sh dhe verifyDump, dhe, nëse migrimi është përgatitur saktë, verifyDump do të tregojë mungesën e ndryshimeve mes DB lokale dhe dump-it të ruajtur

Procesi i pĂ«rshkruar mĂ« sipĂ«r Ă«shtĂ« i pĂ«rshtatshĂ«m me parimet gitflow. Çdo degĂ« nĂ« VCS do tĂ« pĂ«rmbajĂ« versionin e saj tĂ« dump-it, dhe kur bashkohen degĂ«t, bashkohen edhe dump-et. NĂ« shumicĂ«n e rasteve, pas bashkimit nuk kĂ«rkohet asnjĂ« veprim shtesĂ«, por nĂ«se janĂ« bĂ«rĂ« ndryshime nĂ« degĂ« tĂ« ndryshme, pĂ«r shembull, nĂ« tĂ« njĂ«jtĂ«n tabelĂ«, mund tĂ« ndodhi njĂ« konflikt.

Le tĂ« shqyrtojmĂ« njĂ« situatĂ« konfliktuese me shembuj: ka njĂ« degĂ« develop, nga e cila dalin dy degĂ«: feature1 dhe feature2, tĂ« cilat nuk kanĂ« konflikte me develop, por kanĂ« konflikte mes tyre. ËshtĂ« krijuar detyra pĂ«r tĂ« bashkuar tĂ« dy degĂ«t nĂ« develop. PĂ«r kĂ«tĂ« rast rekomandohet fillimisht tĂ« bashkohet njĂ« nga degĂ«t nĂ« develop, dhe pastaj bashkimi develop nĂ« degĂ«n tjetĂ«r, duke zgjidhur nĂ« kĂ«tĂ« mĂ«nyrĂ« konfliktet nĂ« degĂ«n tjetĂ«r, pas sĂ« cilĂ«s bĂ«het bashkimi i degĂ«s sĂ« fundit nĂ« develop. NĂ« fazĂ«n e zgjidhjes sĂ« konflikteve, mund tĂ« nevojitet tĂ« korrigjohet skedari i migrimit nĂ« degĂ«n e fundit, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« pĂ«rputhet me dump-in pĂ«rfundimtar, qĂ« pĂ«rfshin rezultatet e bashkimeve.

Si të depozitohen në mënyrë të sigurtë një numër të madh të ndryshimeve në strukturën e DB në mjedisin production

Falë pranisë në VCS të dump-it të strukturës aktuale të DB, shfaqet mundësia për të verifikuar bazën e prodhimit për përputhshmërinë e saktë me strukturën e kërkuar. Kjo garanton se të gjitha ndryshimet që janë menduar nga zhvilluesit janë transferuar me sukses në bazën e prodhimit.

Sepse DDL në PostgreSQL është transaksionale, rekomandohet të respektohet rendi i mëposhtëm i publikimit, në mënyrë që, në rast të një gabimi të papritur, të bëhet "pa dhimbje" RIVENDOS:

  1. Filloni transaksionin
  2. Në transaksion të zbatohen të gjitha migrimet
  3. Në të njëjtin transaksion të ekzekutohet deployDump
  4. . Pa e përfunduar transaksionin, të ekzekutohet verifyDump. Nëse nuk ka gabime, të ekzekutohet COMMIT. Nëse ka gabime, të ekzekutohet RIVENDOS

Këto hapa janë mjaft lehtësisht të inkorporuar në qasjet ekzistuese të publikimit të aplikacioneve, duke përfshirë zero-downtime.

PĂ«rfundimi

Falë metodave të përshkruara më sipër, mund të nxirret maksimumi i performancës nga projektet "PHP + PostgreSQL", duke sakrifikuar në atë mënyrë një sasi relativisht të vogël të lehtësisë së zhvillimit krahasuar me realizimin e gjithë logjikës së biznesit në kodin kryesor të aplikacionit. Më shumë, përpunimi i të dhënave në PL/pgSQL shpesh duket më transparent dhe kërkon një sasi më të vogël kodi, sesa funksionaliteti i njëjtë, i shkruar në PHP.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster