Tilgangur þessarar greinar er að nota dæmi um bókasafn skema-vörður sýna verkfæri sem geta verulega einfaldað ferlið við að þróa gagnagrunna innan PHP verkefna með því að nota PostgreSQL DBMS.

Upplýsingarnar úr þessari grein munu fyrst og fremst nýtast forriturum sem vilja nýta PostgreSQL getu sem best, en standa frammi fyrir vandamálum við að viðhalda viðskiptarökfræði sem er sett í gagnagrunninn.

Þessi grein mun ekki lýsa kostum eða göllum þess að geyma viðskiptarökfræði í gagnagrunni. Gert er ráð fyrir að valið hafi þegar verið tekið af lesanda.

Eftirfarandi spurningar verða teknar fyrir:

Í hvaða formi ætti að geyma gagnagrunnsuppbyggingu í útgáfustýringarkerfi (hér eftir nefnt VCS)
Hvernig á að fylgjast með breytingum á uppbyggingu gagnagrunnsins eftir að sorphaugur hefur verið vistaður
Hvernig á að flytja breytingar á uppbyggingu gagnagrunnsins yfir í annað umhverfi án árekstra og risastórra flutningsskráa
Hvernig á að skipuleggja ferli samhliða vinnu við verkefni nokkurra hönnuða
Hvernig á að dreifa fleiri breytingum á uppbyggingu gagnagrunnsins á öruggan hátt í framleiðsluumhverfi

SchemaKeeper hannað til að vinna með vistaðar verklagsreglur skrifaðar á tungumálinu PL/pgSQL. Prófun með öðrum tungumálum hefur ekki verið framkvæmd, þannig að notkun gæti ekki verið eins áhrifarík eða ekki möguleg.

Hvernig á að geyma gagnagrunnsskipulag í VCS

Bókasafnið skema-vörður veitir aðgerð saveDump, sem vistar uppbyggingu allra hluta úr gagnagrunninum sem aðskildar textaskrár. Úttakið er skrá sem inniheldur gagnagrunnsbygginguna, skipt í hópaskrár sem auðvelt er að bæta við VCS.

Við skulum skoða að breyta hlutum úr gagnagrunni í skrár með því að nota nokkur dæmi:

Hlutagerð
Kerfið
Nafn
Hlutfallsleg slóð að skrá

Taflan
opinber
reikninga
./public/tables/accounts.txt

Geymd aðferð
opinber
auth (hash bigint)
./public/functions/auth(int8).sql

Inngangur
bókun
gjaldskrár
./booking/views/tariffs.txt

Innihald skránna er textaframsetning á uppbyggingu tiltekins gagnagrunnshluts. Til dæmis, fyrir vistaðar aðgerðir, mun innihald skrárinnar vera full skilgreining á geymdu ferlinu, byrjað á reitnum CREATE OR REPLACE FUNCTION.

Eins og sjá má af töflunni hér að ofan geymir slóðin að skránni upplýsingar um gerð, skema og nafn hlutarins. Þessi aðferð gerir það auðveldara að fletta í gegnum sorphaugur og kóða yfirferð breytinga í gagnagrunninum.

framlenging .sql fyrir skrár með frumkóða geymdra aðferða var þetta valið þannig að IDE veitir sjálfkrafa verkfæri til að hafa samskipti við gagnagrunninn þegar skráin er opnuð.

Hvernig á að fylgjast með breytingum á uppbyggingu gagnagrunnsins eftir að sorphaugur hefur verið vistaður

Með því að vista dump af núverandi gagnagrunnsskipan í VCS fáum við tækifæri til að athuga hvort breytingar hafi verið gerðar á gagnagrunnsskipaninni eftir að dumpið var búið til. Á bókasafni skema-vörður til að greina breytingar á uppbyggingu gagnagrunnsins er aðgerð veitt verifyDump, sem skilar upplýsingum um muninn án aukaverkana.

Önnur leið til að athuga er að hringja í aðgerðina aftur saveDump, tilgreina sömu möppu og athugaðu í VCS fyrir breytingar. Þar sem allir hlutir úr gagnagrunninum eru vistaðir í aðskildum skrám mun VCS aðeins sýna breytta hluti.
Helsti ókosturinn við þessa aðferð er nauðsyn þess að skrifa yfir skrár til að sjá breytingarnar.

Hvernig á að flytja breytingar á uppbyggingu gagnagrunnsins yfir í annað umhverfi án árekstra og risastórra flutningsskráa

Þökk sé aðgerðinni deployDump Hægt er að breyta frumkóða geymdra ferla á nákvæmlega sama hátt og venjulegum frumkóða forrits. Þú getur bætt við / eytt nýjum línum í vistuðum verklagskóða og ýtt strax á breytingar á útgáfustýringu, eða búið til / eytt geymdum verkferlum með því að búa til / eyða samsvarandi skrám í sorpskránni.

Til dæmis, til að búa til nýtt vistað ferli í skema public búðu bara til nýja skrá með viðbótinni .sql í skránni public/functions, settu frumkóðann fyrir geymda ferlið í það, þar á meðal blokkina CREATE OR REPLACE FUNCTION, hringdu síðan í fallið deployDump. Breyting og eyðing vistaðrar aðferðar fer fram á sama hátt. Þannig fer kóðinn inn í bæði VCS og gagnagrunninn á sama tíma.

Ef villa kemur upp í frumkóða einhvers vistaðs ferlis, eða misræmis á milli nafna skráar og vistaðs ferlis, þá deployDump mun mistakast, birtir villutexta. Ósamræmi geymdra ferla milli sorphaugsins og núverandi gagnagrunns er ómögulegt þegar það er notað deployDump.

Þegar nýtt vistað ferli er búið til er engin þörf á að slá inn rétt skráarnafn handvirkt. Það er nóg að skráin hafi endinguna .sql. Eftir símtalið deployDump villutextinn mun innihalda rétt nafn, sem hægt er að nota til að endurnefna skrána.

deployDump gerir þér kleift að breyta færibreytum falls eða skilategundar án frekari aðgerða, en með klassísku aðferðinni þarftu að
framkvæma fyrst DROP FUNCTION, og aðeins þá CREATE OR REPLACE FUNCTION.

Því miður eru nokkrar aðstæður þar sem deployDump ekki hægt að beita breytingum sjálfkrafa. Til dæmis ef kveikjaaðgerð sem er notuð af að minnsta kosti einum kveikju er fjarlægð. Slíkar aðstæður eru leystar handvirkt með því að nota flutningsskrár.

Ef þú ert ábyrgur fyrir því að flytja breytingar á geymdar verklagsreglur skema-vörður, þá verður að nota flutningsskrár til að flytja aðrar breytingar á uppbyggingunni. Til dæmis er gott bókasafn til að vinna með fólksflutninga kenning/flutninga.

Beita þarf flutningum áður en ræst er deployDump. Þetta gerir þér kleift að gera allar breytingar á uppbyggingunni og leysa vandaðar aðstæður þannig að breytingar á geymdum verkferlum eru síðan fluttar án vandræða.

Vinnu við fólksflutninga verður nánar lýst í eftirfarandi köflum.

Hvernig á að skipuleggja ferli samhliða vinnu við verkefni nokkurra hönnuða

Nauðsynlegt er að búa til handrit fyrir fullkomna frumstillingu gagnagrunnsins, sem hleypt er af stokkunum af framkvæmdaraðilanum á vinnuvélinni sinni, sem færir uppbyggingu staðbundins gagnagrunns í samræmi við sorphauginn sem er vistaður í VCS. Auðveldasta leiðin er að skipta frumstillingu staðbundins gagnagrunns í 3 skref:

Flytja inn skrá með grunnbyggingu sem mun heita t.d. base.sql
Að beita fólksflutningum
Hringdu deployDump

base.sql er upphafspunkturinn þar sem flutningum er beitt og framkvæmt deployDumpÞað er, base.sql + миграции + deployDump = актуальная структура БД. Þú getur búið til slíka skrá með því að nota tólið pg_dump. Notað base.sql eingöngu þegar gagnagrunnurinn er frumstilltur frá grunni.

Við skulum kalla á handritið fyrir fullkomna frumstillingu gagnagrunns refresh.sh. Verkflæðið gæti litið svona út:

Framkvæmdaraðilinn kynnir í umhverfi sínu refresh.sh og fær núverandi gagnagrunnsuppbyggingu
Framkvæmdaraðilinn byrjar að vinna að verkefninu sem er fyrir hendi og breytir staðbundnum gagnagrunni til að mæta þörfum nýju virkninnar (ALTER TABLE ... ADD COLUMN o.s.frv.)
Eftir að hafa lokið verkefninu kallar verktaki á aðgerðina saveDumpað framfylgja breytingum sem gerðar eru á gagnagrunninum í VCS
Endurræsa þróunaraðila refresh.sh, þá verifyDumpsem sýnir nú lista yfir breytingar sem á að taka með í flutningnum
Framkvæmdaraðilinn flytur allar skipulagsbreytingar í flutningsskrána, keyrir aftur refresh.sh и verifyDump, og ef flutningurinn er rétt settur saman, verifyDump mun sýna engan mun á staðbundnum gagnagrunni og vistuðu sorpinu

Ferlið sem lýst er hér að ofan er samhæft við meginreglur gitflow. Hvert útibú í VCS mun innihalda sína eigin útgáfu af sorphaugnum og við sameiningu útibúa verða sorphaugarnir sameinaðir. Í flestum tilfellum þarf ekki að grípa til frekari aðgerða eftir sameiningu, en ef breytingar voru gerðar á mismunandi greinum, til dæmis á sömu töflu, geta komið upp átök.

Við skulum íhuga átakaaðstæður með því að nota dæmi: það er útibú þróa, þaðan sem tvær greinar greinast: eiginleiki1 и eiginleiki2, sem ekki eiga í átökum við þróa, en eiga í átökum sín á milli. Verkefnið er að sameina báðar greinarnar í þróa. Í þessu tilviki er mælt með því að sameina fyrst eina af útibúunum í þróaog sameinast síðan þróa til útibúsins sem eftir er, leysa átök í greininni sem eftir er og sameina svo síðasta greinin í þróa. Á meðan á ágreiningsferlinu stendur gætir þú þurft að laga flutningsskrána í síðustu greininni þannig að hún passi við endanlega sorphauginn, sem inniheldur niðurstöður sameininganna.

Hvernig á að dreifa fleiri breytingum á uppbyggingu gagnagrunnsins á öruggan hátt í framleiðsluumhverfi

Þökk sé tilvist sorphaugs núverandi gagnagrunnsuppbyggingar í VCS, verður mögulegt að athuga framleiðslugagnagrunninn fyrir nákvæmlega samræmi við nauðsynlega uppbyggingu. Þetta tryggir að allar breytingar sem framkvæmdaraðilar ætluðu voru færðar yfir í framleiðslustöðina.

Eins og DDL í PostgreSQL er viðskiptaleg, er mælt með því að fylgja eftirfarandi dreifingarröð, svo að ef óvænt villa kemur upp geturðu „sársaukalaust“ framkvæmt ROLLBACK:

Hefja viðskipti
Framkvæma allar flutningar í færslu
Í sömu viðskiptum, framkvæma deployDump
Án þess að klára viðskiptin, framkvæma verifyDump. Ef það eru engar villur skaltu keyra COMMIT. Ef það eru villur skaltu keyra ROLLBACK

Auðvelt er að samþætta þessi skref inn í núverandi aðferðir við uppsetningu forrita, þar á meðal núll niður í miðbæ.

Ályktun

Þökk sé aðferðunum sem lýst er hér að ofan er hægt að kreista hámarksafköst út úr „PHP + PostgreSQL“ verkefnum, en fórna tiltölulega litlum þróunarþægindum samanborið við að innleiða alla viðskiptarökfræði í aðalforritakóðanum. Þar að auki, gagnavinnsla í PL/pgSQL lítur oft gegnsærri út og krefst minni kóða en sömu virkni sem er skrifuð í PHP.

Heimild: www.habr.com

Viðskiptarökfræði í gagnagrunninum með SchemaKeeper