Lògica cummerciale in a basa di dati cù SchemaKeeper

U scopu di stu articulu hè di utilizà l'esempiu di una biblioteca guardianu di schema mostra strumenti chì ponu simplificà significativamente u prucessu di sviluppu di basa di dati in i prughjetti PHP cù u DBMS PostgreSQL.

L'infurmazione di questu articulu serà, prima di tuttu, utile à i sviluppatori chì volenu sfruttà a maiò parte di e capacità di PostgreSQL, ma sò affruntati cù prublemi di mantene a logica di l'affari pusata in a basa di dati.

Questu articulu ùn descrive micca i vantaghji o i disadvantages di almacenà a logica cummerciale in una basa di dati. Si assume chì a scelta hè digià stata fatta da u lettore.

E seguenti dumande seranu cunsiderate:

  1. In quale forma deve esse guardatu un dump di struttura di basa di dati in un sistema di cuntrollu di versione (in seguitu chjamatu VCS)
  2. Cumu seguità i cambiamenti in a struttura di a basa di dati dopu avè salvatu un dump
  3. Cumu trasfiriri cambiamenti in a struttura di basa di dati à altri ambienti senza cunflitti è schedarii di migrazione giganti
  4. Cumu urganizà u prucessu di travagliu parallelu nantu à un prughjettu da parechji sviluppatori
  5. Cumu implementà in modu sicuru più cambiamenti in a struttura di basa di dati in un ambiente di produzzione

    SchemaKeeper cuncepitu per travaglià cù e prucedure almacenate scritte in a lingua PL/pgSQL. A prova cù altre lingue ùn hè micca stata realizata, cusì l'usu pò esse micca cusì efficace o ùn hè micca pussibule.

Cumu almacenà un dump di struttura di basa di dati in VCS

affairs guardianu di schema furnisce una funzione saveDump, chì salva a struttura di tutti l'uggetti da a basa di dati cum'è schedarii di testu separati. L'output hè un repertoriu chì cuntene a struttura di basa di dati, divisa in schedarii raggruppati chì ponu esse facilmente aghjuntu à VCS.

Fighjemu à cunvertisce l'uggetti da una basa di dati in schedari cù parechji esempi:

Tipu d'ughjettu
U schema
Titulu
Percorsu relative à u schedariu

tàvula
pùbblicu
annuali
./public/tables/accounts.txt

Prucedura almacenata
pùbblicu
auth (hash bigint)
./public/functions/auth(int8).sql

Introduzione
Réservation
tariffi
./booking/views/tariffs.txt

U cuntenutu di i schedari sò una rapprisintazioni testuale di a struttura di un oggettu di basa di dati specificu. Per esempiu, per i prucessi almacenati, u cuntenutu di u schedariu serà a definizione completa di a prucedura almacenata, cuminciendu cù u bloccu. CREATE OR REPLACE FUNCTION.

Comu pò esse vistu da a tavula sopra, u percorsu à u schedariu guarda infurmazione nantu à u tipu, schema è nome di l'ughjettu. Stu approcciu facilita a navigazione in u dump and code review of changes in a basa di dati.

allargamentu .sql per i schedari cù u codice fonte di prucedura almacenata, questu hè statu sceltu per chì l'IDE furnisce automaticamente strumenti per interagisce cù a basa di dati quandu u schedariu hè apertu.

Cumu seguità i cambiamenti in a struttura di a basa di dati dopu avè salvatu un dump

Salvendu un dump di a struttura di a basa di dati attuale in VCS, avemu l'uppurtunità di verificà se i cambiamenti sò stati fatti à a struttura di basa di dati dopu chì u dump hè statu creatu. In biblioteca guardianu di schema per detectà cambiamenti in a struttura di basa di dati, una funzione hè furnita verifyDump, chì torna infurmazione nantu à e diffirenzi senza effetti latu.

Un modu alternativu per verificà hè di chjamà a funzione di novu saveDump, specificendu u stessu annuariu, è verificate in VCS per i cambiamenti. Siccomu tutti l'uggetti da a basa di dati sò salvati in schedarii separati, VCS mostrarà solu l'uggetti cambiati.
U principale svantaghju di stu metudu hè a necessità di sovrascrive i schedari per vede i cambiamenti.

Cumu trasfiriri cambiamenti in a struttura di basa di dati à altri ambienti senza cunflitti è schedarii di migrazione giganti

Grazie à a funzione deployDump U codice fonte di e prucedure almacenate pò esse editatu esattamente in u listessu modu cum'è u codice fonte di l'applicazione regulare. Pudete aghjunghje / sguassate novi linee in u codice di prucedura almacenata è immediatamente spinghje i cambiamenti à u cuntrollu di versione, o creà / sguassate e prucedure almacenate creendu / sguassate i fugliali currispondenti in u cartulare dump.

Per esempiu, per creà una nova prucedura almacenata in un schema public basta à creà un novu schedariu cù l'estensione .sql in u cartulare public/functions, Pone u codice fonte di a prucedura almacenata in questu, cumpresu u bloccu CREATE OR REPLACE FUNCTION, poi chjamate a funzione deployDump. A mudificazione è l'eliminazione di una prucedura almacenata si faci in u listessu modu. Cusì, u codice entra in u VCS è a basa di dati à u stessu tempu.

Se un errore appare in u codice fonte di qualsiasi prucedura almacenata, o una discrepanza trà i nomi di u schedariu è a prucedura almacenata, allora deployDump falla, affissendu u testu d'errore. A mismatch of procedures stored between the dump and the current database is impossible when using deployDump.

Quandu crea una nova prucedura almacenata, ùn ci hè bisognu di inserisce manualmente u nome di u schedariu currettu. Hè abbastanza per u schedariu per avè l'estensione .sql. Dopu à a chjama deployDump u testu d'errore cuntene u nome currettu, chì pò esse usatu per rinominà u schedariu.

deployDump permette di cambià i paràmetri di una funzione o di u tipu di ritornu senza azzioni supplementari, mentre chì cù l'approcciu classicu avete bisognu
eseguite prima DROP FUNCTION, è solu allora CREATE OR REPLACE FUNCTION.

Sfurtunatamente, ci sò parechje situazioni induve deployDump incapaci di applicà automaticamente cambiamenti. Per esempiu, se una funzione di trigger chì hè utilizata da almenu un trigger hè eliminata. Tali situazioni sò risolti manualmente cù i schedari di migrazione.

Sè vo site rispunsevuli di a migrazione di cambiamenti à e prucedure almacenate guardianu di schema, allura i schedarii di migrazzioni deve esse usatu per trasfiriri altri cambiamenti in a struttura. Per esempiu, una bona biblioteca per travaglià cù migrazioni hè duttrina/migrazioni.

E migrazioni devenu esse applicate prima di u lanciu deployDump. Questu permette di fà tutti i cambiamenti in a struttura è di risolve situazioni problematiche in modu chì i cambiamenti in i prucedure almacenati sò successivamente trasferiti senza prublemi.

U travagliu cù e migrazioni serà descrittu in più detail in e sezioni seguenti.

Cumu urganizà u prucessu di travagliu parallelu nantu à un prughjettu da parechji sviluppatori

Hè necessariu di creà un script per l'inizializazione cumpleta di a basa di dati, chì serà lanciata da u sviluppatore nantu à a so macchina di travagliu, purtendu a struttura di a basa di dati lucali in cunfurmità cù u dump salvatu in VCS. A manera più faciule hè di dividisce l'inizializazione di a basa di dati lucale in 3 passi:

  1. Importà un schedariu cù una struttura di basa chì serà chjamatu per esempiu. base.sql
  2. Applicazione di Migrazioni
  3. Challenge deployDump

base.sql hè u puntu di partenza nantu à quale e migrazioni sò applicate è eseguite deployDump, questu hè base.sql + миграции + deployDump = актуальная структура БД. Pudete creà un tali schedariu cù l'utilità pg_dump. Adupratu base.sql esclusivamente quandu inizializza a basa di dati da zero.

Chjamemu u script per l'inizializazione cumpleta di a basa di dati refresh.sh. U flussu di travagliu pò esse cusì:

  1. U sviluppatore lancia in u so ambiente refresh.sh è riceve a struttura di basa di dati attuale
  2. U sviluppatore principia u travagliu nantu à u travagliu in manu, mudificà a basa di dati lucale per risponde à i bisogni di a nova funziunalità (ALTER TABLE ... ADD COLUMN ecc)
  3. Dopu à compie u compitu, u sviluppatore chjama a funzione saveDumpper fà i cambiamenti fatti à a basa di dati in VCS
  4. Rilanciamentu di u sviluppatore refresh.sh, allura verifyDumpchì avà mostra una lista di cambiamenti per include in a migrazione
  5. U sviluppatore trasferisce tutti i cambiamenti di struttura à u schedariu di migrazione, corre di novu refresh.sh и verifyDump, è, se a migrazione hè cumpilata currettamente, verifyDump ùn mostrarà nisuna differenza trà a basa di dati lucale è u dump salvatu

U prucessu descritta sopra hè cumpatibile cù i principii di gitflow. Ogni ramu in u VCS cuntene a so propria versione di u dump, è quandu si fusione i rami, i dumps seranu fusionati. In a maiò parte di i casi, nisuna azzione supplementaria deve esse fatta dopu una fusione, ma se i cambiamenti sò stati fatti in diverse rami, per esempiu, à a listessa tavola, un cunflittu pò esse.

Cunsideremu una situazione di cunflittu cù un esempiu: ci hè un ramu Sviluppà, da quale si ramificanu dui rami : funzione1 и funzione2, chì ùn anu micca cunflittu cù Sviluppà, ma anu cunflittu cù l'altri. U compitu hè di unisce i dui rami in Sviluppà. Per questu casu, hè cunsigliatu di unisce prima una di e rami in Sviluppàe poi unisce Sviluppà à u ramu restante, risolve i cunflitti in u ramu restante, è dopu unisce l'ultimu ramu in Sviluppà. Durante a fase di risoluzione di u cunflittu, pudete avè da riparà u schedariu di migrazione in l'ultimu ramu in modu chì currisponde à u dump finale, chì include i risultati di e fusioni.

Cumu implementà in modu sicuru più cambiamenti in a struttura di basa di dati in un ambiente di produzzione

Grazie à a presenza di un dump di a struttura di basa di dati attuale in VCS, diventa pussibule di verificà a basa di dati di produzzione per u cumpletu esatta di a struttura necessaria. Questu assicura chì tutti i cambiamenti chì i sviluppatori intendevanu sò stati trasferiti cù successu à a basa di produzzione.

siccomu DDL in PostgreSQL hè transazzione, hè cunsigliatu di aderisce à l'ordine di implementazione seguente, perchè, in casu d'errore inesperu, pudete eseguisce "senza dolore". ROLLBACK:

  1. Cumincià a transazzione
  2. Eseguite tutte e migrazioni in una transazzione
  3. In a listessa transazzione, eseguite deployDump
  4. Senza compie a transazzione, eseguite verifyDump. Se ùn ci sò micca errori, corre COMMIT. Se ci sò errori, corre ROLLBACK

Questi passi ponu esse facilmente integrati in l'approcciu esistenti di implementazione di l'applicazioni, cumprese zero-downtime.

cunchiusioni

Grazie à i metudi descritti sopra, hè pussibile sprime u massimu rendimentu di i prughjetti "PHP + PostgreSQL", mentre sacrificà relativamente pocu cunvenzione di sviluppu cumparatu cù l'implementazione di tutta a logica cummerciale in u codice di l'applicazione principale. Inoltre, u trattamentu di dati in PL/pgSQL spessu pare più trasparenti è esige menu codice chì a listessa funziunalità scritta in PHP.

Source: www.habr.com

Add a comment