ProHoster > Blog > Pangangasiwa > Logic ng negosyo sa database gamit ang SchemaKeeper

Logic ng negosyo sa database gamit ang SchemaKeeper

Ang layunin ng artikulong ito ay gamitin ang halimbawa ng isang aklatan schema-keeper ipakita ang mga tool na maaaring makabuluhang gawing simple ang proseso ng pagbuo ng mga database sa loob ng mga proyektong PHP gamit ang PostgreSQL DBMS.

Ang impormasyon mula sa artikulong ito, una sa lahat, ay magiging kapaki-pakinabang sa mga developer na gustong sulitin ang mga kakayahan ng PostgreSQL, ngunit nahaharap sa mga problema sa pagpapanatili ng lohika ng negosyo na inilagay sa database.

Hindi ilalarawan ng artikulong ito ang mga pakinabang o disadvantages ng pag-iimbak ng lohika ng negosyo sa isang database. Ipinapalagay na ang pagpili ay ginawa na ng mambabasa.

Ang mga sumusunod na katanungan ay isasaalang-alang:

  1. Sa anong anyo dapat iimbak ang isang database structure dump sa isang version control system (mula rito ay tinutukoy bilang VCS)
  2. Paano subaybayan ang mga pagbabago sa istraktura ng database pagkatapos mag-save ng isang dump
  3. Paano maglipat ng mga pagbabago sa istraktura ng database sa ibang mga kapaligiran na walang mga salungatan at higanteng mga file ng paglipat
  4. Paano ayusin ang proseso ng parallel na trabaho sa isang proyekto ng ilang mga developer
  5. Paano ligtas na mag-deploy ng higit pang mga pagbabago sa istraktura ng database sa isang kapaligiran ng produksyon

    SchemaKeeper idinisenyo para sa pagtatrabaho sa mga nakaimbak na pamamaraan na nakasulat sa wika PL/pgSQL. Ang pagsubok sa ibang mga wika ay hindi pa naisasagawa, kaya ang paggamit ay maaaring hindi kasing epektibo o maaaring hindi posible.

Paano mag-imbak ng isang database structure dump sa VCS

Aklatan schema-keeper nagbibigay ng isang function saveDump, na nagse-save ng istraktura ng lahat ng mga bagay mula sa database bilang hiwalay na mga text file. Ang output ay isang direktoryo na naglalaman ng istraktura ng database, na nahahati sa mga nakagrupong file na madaling maidagdag sa VCS.

Tingnan natin ang pag-convert ng mga bagay mula sa isang database sa mga file gamit ang ilang mga halimbawa:

Uri ng bagay
Ang pamamaraan
Pangalan
Kaugnay na landas sa file

mesa
publiko
account
./public/tables/accounts.txt

Naka-imbak na pamamaraan
publiko
auth(hash bigint)
./public/functions/auth(int8).sql

Panimula
pagtataan
tariffs
./booking/views/tariffs.txt

Ang mga nilalaman ng mga file ay isang textual na representasyon ng istraktura ng isang partikular na object ng database. Halimbawa, para sa mga nakaimbak na pamamaraan, ang mga nilalaman ng file ay ang buong kahulugan ng nakaimbak na pamamaraan, simula sa block CREATE OR REPLACE FUNCTION.

Tulad ng makikita mula sa talahanayan sa itaas, ang path sa file ay nag-iimbak ng impormasyon tungkol sa uri, schema at pangalan ng bagay. Pinapadali ng diskarteng ito ang pag-navigate sa dump at pagsusuri ng code ng mga pagbabago sa database.

palugit .sql para sa mga file na may naka-imbak na procedure source code, ito ay pinili upang ang IDE ay awtomatikong magbigay ng mga tool para sa pakikipag-ugnayan sa database kapag ang file ay binuksan.

Paano subaybayan ang mga pagbabago sa istraktura ng database pagkatapos mag-save ng isang dump

Sa pamamagitan ng pag-save ng isang dump ng kasalukuyang istraktura ng database sa VCS, nakakakuha kami ng pagkakataong suriin kung ang mga pagbabago ay ginawa sa istraktura ng database pagkatapos magawa ang dump. Sa library schema-keeper upang makita ang mga pagbabago sa istraktura ng database, isang function ay ibinigay verifyDump, na nagbabalik ng impormasyon tungkol sa mga pagkakaiba nang walang mga side effect.

Ang isang alternatibong paraan upang suriin ay tawagan muli ang function saveDump, na tumutukoy sa parehong direktoryo, at suriin sa VCS para sa mga pagbabago. Dahil ang lahat ng mga bagay mula sa database ay naka-save sa magkahiwalay na mga file, ang VCS ay magpapakita lamang ng mga binagong bagay.
Ang pangunahing kawalan ng pamamaraang ito ay ang pangangailangan na i-overwrite ang mga file upang makita ang mga pagbabago.

Paano maglipat ng mga pagbabago sa istraktura ng database sa ibang mga kapaligiran na walang mga salungatan at higanteng mga file ng paglipat

Salamat sa function deployDump Ang source code ng mga nakaimbak na pamamaraan ay maaaring i-edit sa eksaktong parehong paraan tulad ng regular na application source code. Maaari kang magdagdag/magtanggal ng mga bagong linya sa stored procedure code at agad na itulak ang mga pagbabago sa version control, o gumawa/magtanggal ng mga stored procedure sa pamamagitan ng paggawa/pagtanggal ng mga kaukulang file sa dump directory.

Halimbawa, upang lumikha ng isang bagong naka-imbak na pamamaraan sa isang schema public gumawa lang ng bagong file na may extension .sql sa direktoryo public/functions, ilagay ang source code ng naka-imbak na pamamaraan sa loob nito, kasama ang block CREATE OR REPLACE FUNCTION, pagkatapos ay tawagan ang function deployDump. Ang pagbabago at pagtanggal ng nakaimbak na pamamaraan ay nangyayari sa parehong paraan. Kaya, ang code ay napupunta sa parehong VCS at ang database sa parehong oras.

Kung lumilitaw ang isang error sa source code ng anumang nakaimbak na pamamaraan, o isang pagkakaiba sa pagitan ng mga pangalan ng file at ng nakaimbak na pamamaraan, kung gayon deployDump ay mabibigo, na nagpapakita ng teksto ng error. Ang hindi pagkakatugma ng mga nakaimbak na pamamaraan sa pagitan ng dump at ng kasalukuyang database ay imposible kapag ginagamit deployDump.

Kapag lumilikha ng isang bagong naka-imbak na pamamaraan, hindi na kailangang manu-manong ipasok ang tamang pangalan ng file. Ito ay sapat na para sa file na magkaroon ng extension .sql. Pagkatapos ng tawag deployDump ang teksto ng error ay maglalaman ng tamang pangalan, na maaaring magamit upang palitan ang pangalan ng file.

deployDump nagbibigay-daan sa iyo na baguhin ang mga parameter ng isang function o uri ng pagbabalik nang walang karagdagang mga aksyon, habang sa klasikal na diskarte ay kailangan mong
execute muna DROP FUNCTION, at pagkatapos lamang CREATE OR REPLACE FUNCTION.

Sa kasamaang palad, may ilang mga sitwasyon kung saan deployDump hindi awtomatikong mailapat ang mga pagbabago. Halimbawa, kung ang isang trigger function na ginagamit ng hindi bababa sa isang trigger ay aalisin. Ang mga ganitong sitwasyon ay manu-manong nareresolba gamit ang mga migration file.

Kung responsable ka sa paglipat ng mga pagbabago sa mga nakaimbak na pamamaraan schema-keeper, kung gayon ang mga migration file ay dapat gamitin upang ilipat ang iba pang mga pagbabago sa istraktura. Halimbawa, ang isang magandang library para sa pagtatrabaho sa mga migrasyon ay doktrina/migrasyon.

Dapat ilapat ang mga paglilipat bago ilunsad deployDump. Ito ay nagpapahintulot sa iyo na gawin ang lahat ng mga pagbabago sa istraktura at lutasin ang mga problemang sitwasyon upang ang mga pagbabago sa mga nakaimbak na pamamaraan ay kasunod na mailipat nang walang mga problema.

Ang paggawa sa mga migrasyon ay ilalarawan nang mas detalyado sa mga sumusunod na seksyon.

Paano ayusin ang proseso ng parallel na trabaho sa isang proyekto ng ilang mga developer

Kinakailangang lumikha ng isang script para sa kumpletong pagsisimula ng database, na ilulunsad ng developer sa kanyang work machine, na dinadala ang istraktura ng lokal na database alinsunod sa dump na naka-save sa VCS. Ang pinakamadaling paraan ay hatiin ang pagsisimula ng lokal na database sa 3 hakbang:

  1. Mag-import ng file na may pangunahing istraktura na tatawagin hal. base.sql
  2. Paglalapat ng Migrasyon
  3. Hamon deployDump

base.sql ay ang panimulang punto kung saan inilalapat at isinasagawa ang mga paglilipat deployDumpIyon ay, base.sql + ΠΌΠΈΠ³Ρ€Π°Ρ†ΠΈΠΈ + deployDump = Π°ΠΊΡ‚ΡƒΠ°Π»ΡŒΠ½Π°Ρ структура Π‘Π”. Maaari kang lumikha ng ganoong file gamit ang utility pg_dump. Ginamit base.sql eksklusibo kapag sinisimulan ang database mula sa simula.

Tawagan natin ang script para sa kumpletong pagsisimula ng database refresh.sh. Ang daloy ng trabaho ay maaaring magmukhang ganito:

  1. Naglulunsad ang developer sa kanyang kapaligiran refresh.sh at nakukuha ang kasalukuyang istraktura ng database
  2. Sinimulan ng developer ang gawain sa gawain, binabago ang lokal na database upang matugunan ang mga pangangailangan ng bagong pag-andar (ALTER TABLE ... ADD COLUMN atbp)
  3. Matapos makumpleto ang gawain, tinawag ng developer ang function saveDumpupang gumawa ng mga pagbabagong ginawa sa database sa VCS
  4. Muling inilunsad ang developer refresh.shpagkatapos verifyDumpna nagpapakita na ngayon ng listahan ng mga pagbabagong isasama sa paglipat
  5. Inilipat ng developer ang lahat ng pagbabago sa istraktura sa migration file, tatakbo muli refresh.sh ΠΈ verifyDump, at, kung ang paglipat ay naipon nang tama, verifyDump ay hindi magpapakita ng mga pagkakaiba sa pagitan ng lokal na database at ang naka-save na dump

Ang prosesong inilarawan sa itaas ay katugma sa mga prinsipyo ng gitflow. Ang bawat sangay sa VCS ay maglalaman ng sarili nitong bersyon ng dump, at kapag pinagsasama ang mga sangay, ang mga dump ay isasama. Sa karamihan ng mga kaso, walang karagdagang aksyon ang kailangang gawin pagkatapos ng isang pagsasanib, ngunit kung ang mga pagbabago ay ginawa sa iba't ibang sangay, halimbawa, sa parehong talahanayan, maaaring magkaroon ng salungatan.

Isaalang-alang natin ang isang sitwasyon ng salungatan gamit ang isang halimbawa: mayroong isang sangay magbuo, kung saan dalawang sangay ang sangay: tampok1 ΠΈ tampok2, na walang salungatan sa magbuo, ngunit may mga salungatan sa isa't isa. Ang gawain ay pagsamahin ang dalawang sangay sa magbuo. Para sa kasong ito, inirerekomenda na pagsamahin muna ang isa sa mga sangay magbuoat pagkatapos ay pagsamahin magbuo sa natitirang sangay, niresolba ang mga salungatan sa natitirang sangay, at pagkatapos ay pagsasamahin ang huling sangay sa magbuo. Sa yugto ng paglutas ng salungatan, maaaring kailanganin mong ayusin ang file ng paglilipat sa huling sangay upang tumugma ito sa huling dump, na kinabibilangan ng mga resulta ng mga pagsasanib.

Paano ligtas na mag-deploy ng higit pang mga pagbabago sa istraktura ng database sa isang kapaligiran ng produksyon

Salamat sa pagkakaroon ng isang dump ng kasalukuyang istraktura ng database sa VCS, nagiging posible na suriin ang database ng produksyon para sa eksaktong pagsunod sa kinakailangang istraktura. Tinitiyak nito na ang lahat ng mga pagbabago na nilayon ng mga developer ay matagumpay na nailipat sa production base.

Bilang DDL sa PostgreSQL ay transactional, inirerekumenda na sumunod sa sumusunod na pagkakasunud-sunod ng pag-deploy, upang, sa kaso ng hindi inaasahang error, maaari mong "walang sakit" na maisagawa ROLLBACK:

  1. Simulan ang transaksyon
  2. Isagawa ang lahat ng paglilipat sa isang transaksyon
  3. Sa parehong transaksyon, isagawa deployDump
  4. Nang hindi nakumpleto ang transaksyon, isagawa verifyDump. Kung walang mga error, tumakbo COMMIT. Kung may mga error, tumakbo ROLLBACK

Ang mga hakbang na ito ay madaling maisama sa mga umiiral nang diskarte sa pag-deploy ng application, kabilang ang zero-downtime.

Konklusyon

Salamat sa mga pamamaraan na inilarawan sa itaas, posibleng i-squeeze ang maximum na performance mula sa mga proyektong β€œPHP + PostgreSQL”, habang isinasakripisyo ang medyo maliit na kaginhawaan sa pag-unlad kumpara sa pagpapatupad ng lahat ng business logic sa pangunahing application code. Bukod dito, ang pagproseso ng data sa PL/pgSQL madalas na mukhang mas transparent at nangangailangan ng mas kaunting code kaysa sa parehong functionality na nakasulat sa PHP.

Pinagmulan: www.habr.com

Magdagdag ng komento