Pwrpas yr erthygl hon yw defnyddio'r enghraifft o lyfrgell sgema-geidwad dangos offer a all symleiddio'n sylweddol y broses o ddatblygu cronfeydd data o fewn prosiectau PHP gan ddefnyddio DBMS PostgreSQL.

Bydd y wybodaeth o'r erthygl hon, yn gyntaf oll, yn ddefnyddiol i ddatblygwyr sydd am wneud y gorau o alluoedd PostgreSQL, ond sy'n wynebu problemau wrth gynnal rhesymeg busnes a osodir yn y gronfa ddata.

Ni fydd yr erthygl hon yn disgrifio manteision neu anfanteision storio rhesymeg busnes mewn cronfa ddata. Tybir fod y dewisiad eisioes wedi ei wneyd gan y darllenydd.

Bydd y cwestiynau canlynol yn cael eu hystyried:

Ym mha ffurf y dylid storio dymp strwythur cronfa ddata mewn system rheoli fersiynau (y cyfeirir ati o hyn ymlaen fel VCS)
Sut i olrhain newidiadau yn strwythur y gronfa ddata ar ôl arbed dymp
Sut i drosglwyddo newidiadau yn strwythur y gronfa ddata i amgylcheddau eraill heb wrthdaro a ffeiliau mudo enfawr
Sut i drefnu'r broses o waith cyfochrog ar brosiect gan sawl datblygwr
Sut i ddefnyddio mwy o newidiadau yn strwythur y gronfa ddata yn ddiogel i amgylchedd cynhyrchu

Ceidwad Sgema wedi'u cynllunio ar gyfer gweithio gyda gweithdrefnau sydd wedi'u storio wedi'u hysgrifennu yn yr iaith PL/pgSQL. Nid yw profion gydag ieithoedd eraill wedi'u cynnal, felly efallai na fydd defnydd mor effeithiol neu efallai na fydd yn bosibl.

Sut i storio dymp strwythur cronfa ddata yn VCS

Llyfrgell sgema-geidwad yn darparu swyddogaeth saveDump, sy'n arbed strwythur yr holl wrthrychau o'r gronfa ddata fel ffeiliau testun ar wahân. Mae'r allbwn yn gyfeiriadur sy'n cynnwys strwythur y gronfa ddata, wedi'i rannu'n ffeiliau wedi'u grwpio y gellir eu hychwanegu'n hawdd at VCS.

Edrychwn ar drosi gwrthrychau o gronfa ddata yn ffeiliau gan ddefnyddio sawl enghraifft:

Math o wrthrych
Cynllun
Enw
Llwybr cymharol i ffeil

tabl
cyhoeddus
cyfrifon
./public/tables/accounts.txt

Gweithdrefn wedi'i storio
cyhoeddus
auth(hash bigint)
./public/functions/auth(int8).sql

Cyflwyniad
archebu
tariffau
./booking/views/tariffs.txt

Mae cynnwys y ffeiliau yn gynrychioliad testunol o strwythur gwrthrych cronfa ddata penodol. Er enghraifft, ar gyfer gweithdrefnau storio, cynnwys y ffeil fydd y diffiniad llawn o'r weithdrefn storio, gan ddechrau gyda'r bloc CREATE OR REPLACE FUNCTION.

Fel y gwelir o'r tabl uchod, mae'r llwybr i'r ffeil yn storio gwybodaeth am y math, sgema ac enw'r gwrthrych. Mae'r dull hwn yn ei gwneud hi'n haws llywio drwy'r adolygiad dympio a chod o newidiadau yn y gronfa ddata.

estyniad .sql ar gyfer ffeiliau gyda chod ffynhonnell gweithdrefn wedi'i storio, dewiswyd hwn fel bod y DRhA yn darparu offer yn awtomatig ar gyfer rhyngweithio â'r gronfa ddata pan fydd y ffeil yn cael ei hagor.

Sut i olrhain newidiadau yn strwythur y gronfa ddata ar ôl arbed dymp

Trwy arbed adeiledd cronfa ddata gyfredol yn VCS, cawn gyfle i wirio a wnaethpwyd newidiadau i strwythur y gronfa ddata ar ôl creu'r dymp. Yn y llyfrgell sgema-geidwad i ganfod newidiadau yn strwythur y gronfa ddata, darperir swyddogaeth verifyDump, sy'n dychwelyd gwybodaeth am y gwahaniaethau heb sgîl-effeithiau.

Ffordd arall o wirio yw galw'r swyddogaeth eto saveDump, gan nodi'r un cyfeiriadur, a gwirio yn VCS am newidiadau. Gan fod yr holl wrthrychau o'r gronfa ddata yn cael eu cadw mewn ffeiliau ar wahân, bydd VCS yn dangos gwrthrychau sydd wedi newid yn unig.
Prif anfantais y dull hwn yw'r angen i drosysgrifo ffeiliau er mwyn gweld y newidiadau.

Sut i drosglwyddo newidiadau yn strwythur y gronfa ddata i amgylcheddau eraill heb wrthdaro a ffeiliau mudo enfawr

Diolch i'r swyddogaeth deployDump Gellir golygu cod ffynhonnell y gweithdrefnau sydd wedi'u storio yn union yr un ffordd â chod ffynhonnell y cymhwysiad rheolaidd. Gallwch ychwanegu / dileu llinellau newydd yn y cod gweithdrefn sydd wedi'i storio a gwthio newidiadau ar unwaith i reolaeth fersiwn, neu greu / dileu gweithdrefnau sydd wedi'u storio trwy greu / dileu'r ffeiliau cyfatebol yn y cyfeiriadur dympio.

Er enghraifft, i greu gweithdrefn storio newydd mewn sgema public dim ond creu ffeil newydd gyda'r estyniad .sql yn y cyfeiriadur public/functions, rhowch god ffynhonnell y weithdrefn storio ynddo, gan gynnwys y bloc CREATE OR REPLACE FUNCTION, yna ffoniwch y swyddogaeth deployDump. Mae addasu a dileu gweithdrefn wedi'i storio yn digwydd yn yr un modd. Felly, mae'r cod yn mynd i mewn i'r VCS a'r gronfa ddata ar yr un pryd.

Os bydd gwall yn ymddangos yng nghod ffynhonnell unrhyw weithdrefn sydd wedi'i storio, neu anghysondeb rhwng enwau'r ffeil a'r weithdrefn sydd wedi'i storio, yna deployDump yn methu, gan ddangos testun gwall. Mae anghydweddu gweithdrefnau storio rhwng y domen a'r gronfa ddata gyfredol yn amhosibl wrth ei defnyddio deployDump.

Wrth greu gweithdrefn storio newydd, nid oes angen nodi'r enw ffeil cywir â llaw. Mae'n ddigon i'r ffeil gael yr estyniad .sql. Ar ôl yr alwad deployDump bydd testun y gwall yn cynnwys yr enw cywir, y gellir ei ddefnyddio i ailenwi'r ffeil.

deployDump yn eich galluogi i newid paramedrau swyddogaeth neu fath dychwelyd heb gamau gweithredu ychwanegol, tra gyda'r dull clasurol y byddai'n rhaid i chi
gweithredu yn gyntaf DROP FUNCTION, a dim ond wedyn CREATE OR REPLACE FUNCTION.

Yn anffodus, mae yna rai sefyllfaoedd lle deployDump methu â gweithredu newidiadau yn awtomatig. Er enghraifft, os caiff swyddogaeth sbardun a ddefnyddir gan o leiaf un sbardun ei ddileu. Mae sefyllfaoedd o'r fath yn cael eu datrys â llaw gan ddefnyddio ffeiliau mudo.

Os ydych yn gyfrifol am fudo newidiadau i weithdrefnau storio sgema-geidwad, yna rhaid defnyddio ffeiliau mudo i drosglwyddo newidiadau eraill yn y strwythur. Er enghraifft, mae llyfrgell dda ar gyfer gweithio gyda mudo athrawiaeth/ymfudiadau.

Rhaid cymhwyso ymfudiadau cyn lansio deployDump. Mae hyn yn caniatáu ichi wneud yr holl newidiadau i'r strwythur a datrys sefyllfaoedd problemus fel bod newidiadau mewn gweithdrefnau storio yn cael eu trosglwyddo heb unrhyw broblemau.

Disgrifir gweithio gyda mudo yn fanylach yn yr adrannau canlynol.

Sut i drefnu'r broses o waith cyfochrog ar brosiect gan sawl datblygwr

Mae angen creu sgript ar gyfer cychwyniad cyflawn y gronfa ddata, a fydd yn cael ei lansio gan y datblygwr ar ei beiriant gwaith, gan ddod â strwythur y gronfa ddata leol yn unol â'r domen a arbedwyd yn VCS. Y ffordd hawsaf yw rhannu cychwyniad y gronfa ddata leol yn 3 cham:

Mewnforio ffeil gyda strwythur sylfaenol a fydd yn cael ei galw e.e. base.sql
Cymhwyso Ymfudiadau
Her deployDump

base.sql yw'r man cychwyn ar ben hyn y mae ymfudiadau yn cael eu cymhwyso a'u gweithredu deployDumpHynny yw, base.sql + миграции + deployDump = актуальная структура БД. Gallwch greu ffeil o'r fath gan ddefnyddio'r cyfleustodau pg_dump. Defnyddiwyd base.sql yn unig wrth gychwyn y gronfa ddata o'r dechrau.

Gadewch i ni alw'r sgript ar gyfer ymgychwyn cronfa ddata gyflawn refresh.sh. Efallai y bydd y llif gwaith yn edrych fel hyn:

Mae'r datblygwr yn lansio yn ei amgylchedd refresh.sh ac yn cael y strwythur cronfa ddata gyfredol
Mae'r datblygwr yn dechrau gweithio ar y dasg dan sylw, gan addasu'r gronfa ddata leol i ddiwallu anghenion y swyddogaeth newydd (ALTER TABLE ... ADD COLUMN ac ati)
Ar ôl cwblhau'r dasg, mae'r datblygwr yn galw'r swyddogaeth saveDumpymrwymo newidiadau i'r gronfa ddata yn VCS
Datblygwr yn ail-lansio refresh.shyna verifyDumpsydd bellach yn dangos rhestr o newidiadau i'w cynnwys yn y mudo
Mae'r datblygwr yn trosglwyddo'r holl newidiadau strwythur i'r ffeil mudo, yn rhedeg eto refresh.sh и verifyDump, ac, os caiff yr ymfudiad ei lunio'n gywir, verifyDump ni fydd yn dangos unrhyw wahaniaethau rhwng y gronfa ddata leol a'r domen sydd wedi'i chadw

Mae'r broses a ddisgrifir uchod yn gydnaws ag egwyddorion gitflow. Bydd pob cangen yn y VCS yn cynnwys ei fersiwn ei hun o'r domen, ac wrth uno canghennau, bydd y tomenni'n cael eu huno. Yn y rhan fwyaf o achosion, nid oes angen cymryd unrhyw gamau ychwanegol ar ôl uno, ond pe bai newidiadau'n cael eu gwneud mewn gwahanol ganghennau, er enghraifft, i'r un tabl, gallai gwrthdaro godi.

Gadewch i ni ystyried sefyllfa o wrthdaro gan ddefnyddio enghraifft: mae cangen datblygu, o ba ddwy gangen y cangen : nodwedd1 и nodwedd2, sydd heb unrhyw wrthdaro â datblygu, ond yn gwrthdaro â'i gilydd. Y dasg yw uno'r ddwy gangen i mewn datblygu. Yn yr achos hwn, argymhellir uno un o'r canghennau yn gyntaf datblyguac yna uno datblygu i'r gangen sy'n weddill, gan ddatrys gwrthdaro yn y gangen sy'n weddill, ac yna uno'r gangen olaf i mewn datblygu. Yn ystod y cam datrys gwrthdaro, efallai y bydd yn rhaid i chi drwsio'r ffeil ymfudo yn y gangen olaf fel ei bod yn cyfateb i'r domen derfynol, sy'n cynnwys canlyniadau'r uno.

Sut i ddefnyddio mwy o newidiadau yn strwythur y gronfa ddata yn ddiogel i amgylchedd cynhyrchu

Diolch i bresenoldeb tomen o strwythur y gronfa ddata gyfredol yn VCS, mae'n bosibl gwirio'r gronfa ddata gynhyrchu i weld a yw'n cydymffurfio'n union â'r strwythur gofynnol. Mae hyn yn sicrhau bod yr holl newidiadau a fwriadwyd gan y datblygwyr yn cael eu trosglwyddo'n llwyddiannus i'r sylfaen gynhyrchu.

Fel DDL yn PostgreSQL yn trafodol, argymhellir cadw at y gorchymyn defnyddio canlynol, fel y gallwch chi, rhag ofn y bydd gwall annisgwyl, weithredu yn “ddi-boen” ROLLBACK:

Dechrau trafodiad
Perfformio pob mudo mewn trafodiad
Yn yr un trafodiad, gweithredu deployDump
Heb gwblhau'r trafodiad, gweithredu verifyDump. Os nad oes unrhyw wallau, rhedeg COMMIT. Os oes gwallau, rhedeg ROLLBACK

Gellir integreiddio'r camau hyn yn hawdd i'r dulliau presennol o ddefnyddio cymwysiadau, gan gynnwys dim amser segur.

Casgliad

Diolch i'r dulliau a ddisgrifir uchod, mae'n bosibl gwasgu'r perfformiad mwyaf allan o brosiectau "PHP + PostgreSQL", tra'n aberthu cymharol ychydig o gyfleustra datblygu o'i gymharu â gweithredu'r holl resymeg busnes yn y prif god cais. Ar ben hynny, prosesu data yn PL/pgSQL yn aml yn edrych yn fwy tryloyw ac yn gofyn am lai o god na'r un swyddogaeth a ysgrifennwyd yn PHP.

Ffynhonnell: hab.com

Rhesymeg busnes yn y gronfa ddata gan ddefnyddio SchemaKeeper