ProHoster > Blog > Administrim > Logjika e biznesit në bazën e të dhënave përmes SchemaKeeper

Logjika e biznesit në bazën e të dhënave përmes SchemaKeeper

Qëllimi i këtij artikulli është të tregojë, përmes bibliotekës schema-keeper mjetet që lehtësojnë ndjeshëm procesin e zhvillimit të bazave të të dhënave në projektet PHP që përdorin DBMS PostgreSQL.

Informacioni në këtë artikull do të jetë sidomos i dobishëm për zhvilluesit që dëshirojnë të shfrytëzojnë sa më shumë mundësitë e PostgreSQL, por hasin vështirësi në mbështetje të logjikës së biznesit të outsourcuara 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. Supozohet se zgjedhja është bërë nga lexuesi.

Do të shqyrtohen pyetje të tilla si:

  1. Në cilën formë të ruhet dumpsi i strukturës së DB në sistemin e kontrollit të versioneve (VCS)
  2. Si të ndjekim ndryshimet në strukturën e DB pas ruajtjes së dumpsit
  3. Si të transferojmë ndryshimet në strukturën e DB në mjedise të tjera pa konflikte dhe skedarë migracionesh gjigande
  4. Si të organizojmë procesin e punës paralele mbi projektin me disa zhvillues
  5. Si të deployohet në siguri një numër të madh ndryshimesh në strukturën e DB në ambientin production

    SchemaKeeper është i optimizuar për punë me procedurat e ruajtura të shkruara në gjuhën PL/pgSQL. Testimi me gjuhë të tjera nuk është kryer, për pasojë përdorimi mund të mos jetë kaq efektiv, ose të jetë i pamundur.

Në cilën formë të ruhet dumpsi 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ë përfundim krijohet një direktorium që përmban strukturën e DB, e cila është e ndarë në skedarë të grupuar që lehtë mund të shtohen në VCS.

Le të shqyrtojmë transformimin e objekteve nga DB në skedarë përmes disa shembujsh:

Tipi i objektit
Skema
Emri
Rruga e relatshme drejt skedarit

Tavolina
public
accounts
./public/tables/accounts.txt

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

Përfaqësimi
booking
tariffs
./booking/views/tariffs.txt

Përmbajtja e skedarëve është një përfaqësim të tekstit të strukturës së objektit të caktuar të DB. Për shembull, për procedurat e ruajtura, përmbajtja e skedarit do të jetë definicioni i plotë i procedurës së ruajtur, që fillon me bllokun CREATE OR REPLACE FUNCTION.

Siç shihet nga tabela e mësipërme, rruga e skedarit mban informacionin për tipin, skemën dhe emrin e objektit. Kjo qasje lehtëson navigimin në dumps dhe shqyrtimin e ndryshimeve në DB.

Zgjerim .sql për skedarët me kodin burimor të procedurave të ruajtura, është zgjedhur që IDE të ofrojnë automatikisht mjete për ndërveprimin me Baza të Dhënash kur hapet skedari.

Si të ndjekim ndryshimet në strukturën e DB pas ruajtjes së dumpsit

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

Një mënyrë alternative verifikimi është të thërrasësh përsëri funksionin saveDump, duke treguar të njëjtën drejtorinë, dhe të kontrollosh në VCS për ndryshime. Ngjashëm me që të gjitha objektet nga Baza të Dhënash janë ruajtur në skedarë të veçantë, VCS do të tregojë vetëm objektet e ndryshuara.
Disavantazhi kryesor i kësaj metode është se duhet të ri-shkruhen skedarët për të parë ndryshimet.

Si të transferojmë ndryshimet në strukturën e DB në mjedise të tjera pa konflikte dhe skedarë migracionesh gjigande

Falë funksionit deployDump kodi burimor i procedurave të ruajtura mund të redaktohet në mënyrë të njëjtë siç bëhet me kodin e zakonshëm të aplikacionit. Mund të shtohen/faqen rreshta të rinj në kodin e procedurave të ruajtura dhe menjëherë të dërgohen ndryshimet në sistemin e kontrollit të versioneve, ose të krijohen/fshihen procedurat e ruajtura duke krijuar/fshirë skedarët përkatës në drejtorinë e dump-it.

Për shembull, për të krijuar një procedurë të re të ruajtur në skemën public mjafton të krijosh një skedar të ri me shtesën .sql në drejtorinë public/functions, të vendosësh në të kodin burimor të procedurës së ruajtur, duke përfshirë blokun CREATE OR REPLACE FUNCTION, pastaj të thërrasësh funksionin deployDump. Në mënyrë të ngjashme ndodh ndryshimi dhe fshirja e procedurës së ruajtur. Në këtë mënyrë, kodi përfshihet njëkohësisht në VCS dhe në Baza të Dhënash.

Nëse në kodin burimor të ndonjë procedure të ruajtur ndodh një gabim, ose një moskonsistencë mes emrave të skedarëve dhe procedurës së ruajtur, atëherë deployDump nuk do të kryhet, duke treguar tekstin e gabimit. Moskonsistenca e procedurave të ruajtura mes dump-it dhe Baza të Dhënash aktuale është e pamundur kur përdoret deployDump.

Kur krijohet një procedurë e re e ruajtur, nuk është e nevojshme të shkruhet dorazi emri i saktë i skedarit. Mjafton që skedari të ketë shtesën .sql. Pas thirrjes 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 ndryshimin e parametrave të funksionit ose llojit të kthyer pa veprime të tjera, ndërsa sipas qasjes klasike do të duhej
fillimisht të ekzekutonte DROP FUNCTION, dhe vetëm pastaj CREATE OR REPLACE FUNCTION.

Fatkeq, ekzistojnë disa situata kur deployDump nuk është e mundur të aplikohet automatikisht ndryshimet. Për shembull, nëse hiqet një funksion aktivizues që përdoret nga të paktën një aktivizues. Këto situata zgjidhen manualisht përmes skedave të migrimeve.

Nëse transferimin e ndryshimeve në procedurat e ruajtura e bën vetë schema-keeper, atëherë për të transferuar ndryshimet e tjera në strukturë është e nevojshme të përdoren skedat e migrimeve. Për shembull, një bibliotekë e mirë për punën me migrimet është doctrine/migrations.

Migrimet duhet të aplikohen para se të fillojë deployDump. Kjo lejon që të bëhen të gjitha ndryshimet në strukturë dhe të zgjidhen situatat problematike që të transferohen pa probleme ndryshimet në procedurat e ruajtura më vonë.

Më shumë në detaje, puna me migrimet do të përshkruhet në seksionet në vazhdim.

Si të organizojmë procesin e punës paralele mbi projektin me disa zhvillues

ËshtĂ« e nevojshme tĂ« krijohet njĂ« skenar i plotĂ« i inicializimit tĂ« DB-sĂ«, i cili do tĂ« ekzekutohet nga zhvilluesi nĂ« makinĂ«n e tij tĂ« punĂ«s, duke e sjellĂ« strukturĂ«n e DB-sĂ« lokale nĂ« pĂ«rputhje me dump-in e ruajtur nĂ« VCS. MĂ« lehtĂ« Ă«shtĂ« tĂ« ndahet inicializimi i DB-sĂ« lokale nĂ« 3 hapa:

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

base.sql — kjo Ă«shtĂ« pika e nisjes, mbi tĂ« cilĂ«n aplikohen migrimet dhe ekzekutohet deployDump, qĂ« do tĂ« thotĂ« base.sql + migrimet + deployDump = struktura aktuale e DB-sĂ«. NjĂ« skedar tĂ« tillĂ« mund tĂ« formohet pĂ«rmes utilitarit pg_dump. PĂ«rdoret base.sql pĂ«r vetĂ« inicializimin e bazĂ«s sĂ« tĂ« dhĂ«nave nga fillimi.

Ta quajmë skenarin e plotë të inicializimit të DB-së refresh.sh. Procesi i punës mund të duket si më poshtë:

  1. Zhvilluesi ekzekuton në mjedisin e tij refresh.sh dhe merr strukturën aktuale të DB-së
  2. Zhvilluesi fillon të punojë mbi detyrën e caktuar, duke modifikuar DB-në 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 listën e ndryshimeve për t'u përfshirë në migrim
  5. Zhvilluesi transferon të gjitha ndryshimet në strukturë në skedarin e migrimit, ekzekuton përsëri refresh.sh dhe verifyDump, dhe, nëse migrimi është përgatitur saktë, verifyDump do të tregojë se nuk ka dallime midis DB-së lokale dhe dump-it të ruajtur.

Procesi tĂ« pĂ«rshkruar mĂ« sipĂ«r Ă«shtĂ« pĂ«rputhshĂ«m me parimet e gitflow. Çdo degĂ« nĂ« VCS do tĂ« pĂ«rmbajĂ« versionin e vet tĂ« dump-it, dhe kur degĂ«t bashkohen, do tĂ« ndodhĂ« bashkimi i dump-Ă«ve. NĂ« shumicĂ«n e rasteve, pas bashkimit nuk nevojitet tĂ« merren masa tĂ« tjera, 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ë konflikti me shembuj: ka një degë develop, nga e cila janë ndarë dy degë: feature1 dhe feature2, të cilat nuk kanë konflikte me develop, por kanë konflikte midis tyre. Detyra është të bëhet bashkimi i të dyve degë në develop. Në këtë rast, rekomandohet së pari të bëhet bashkimi i njërit prej degëve në develop, e më pas bashkimi develop në degën tjetër, duke zgjidhur konflikte në degën e mbetur, dhe më pas të bëhet bashkimi i degës së fundit në develop. Në fazën e zgjidhjes së konflikteve, mund të jetë e nevojshme të korrigjohet skedari i migrimit në degën e fundit, në mënyrë që të përputhej me dump-in përfundimtar, i cili përfshin rezultatet e bashkimeve.

Si të deployohet në siguri një numër të madh ndryshimesh në strukturën e DB në ambientin production

Duke pasur në VCS dump-in e strukturës aktuale të DB-së, krijohet mundësia për të verifikuar bazën e të dhënave në prodhim për përputhshmërinë e saktë me strukturën e kërkuar. Kjo garanton që të gjitha ndryshimet, që kishin parashikuar zhvilluesit, janë transferuar me sukses në bazën e të dhënave në prodhim.

Meqenëse DDL në PostgreSQL është transaksional, rekomandohet që të ndiqet rendi i mëposhtëm i depot, në mënyrë që, në rast të një gabimi të papritur, të mund të bëhet një ROLLBACK:

  1. Të fillojë transaksionin
  2. Të bëhen të gjitha migrimet në transaksion
  3. Në këtë transaksion të bëhet deployDump
  4. Pa përfunduar transaksionin, të bëhet verifyDump. Nëse nuk ka gabime, të bëhet KREJT. Nëse ka gabime, të bëhet ROLLBACK

Këto hapat janë mjaft të lehta për t'u integruar në qasjet ekzistente për depolimin e aplikacioneve, përfshirë zero-downtime.

PĂ«rfundim

Falë metodave të përshkruara më sipër, është e mundur të nxjerrim maksimumin e performancës nga projektet "PHP + PostgreSQL", duke sakrifikuar një sasi relativisht të vogël të lehtësisë që ofron zhvillimi krahasuar me realizimin e gjithë logjikës së biznesit në kodin kryesor të aplikacionit. Për më tepër, përpunimi i të dhënave në PL/pgSQL shpesh duket më transparent dhe kërkon më pak kod sesa funksionaliteti i njëjtë i shkruar në PHP.

Burimi: habr.com

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