L'objectiu d'aquest article és utilitzar l'exemple d'una biblioteca responsable d'esquemes mostrar eines que poden simplificar significativament el procés de desenvolupament de bases de dades dins de projectes PHP mitjançant el SGBD PostgreSQL.

La informació d'aquest article serà, en primer lloc, útil per als desenvolupadors que volen treure el màxim profit de les capacitats de PostgreSQL, però que s'enfronten a problemes per mantenir la lògica empresarial col·locada a la base de dades.

Aquest article no descriurà els avantatges o els desavantatges d'emmagatzemar la lògica empresarial en una base de dades. Se suposa que l'elecció ja l'ha fet el lector.

Es tindran en compte les preguntes següents:

1. De quina forma s'ha d'emmagatzemar un abocament d'estructura de base de dades en un sistema de control de versions (d'ara endavant anomenat VCS)
2. Com fer el seguiment dels canvis a l'estructura de la base de dades després de desar un bolcat
3. Com transferir els canvis a l'estructura de la base de dades a altres entorns sense conflictes i fitxers de migració gegants
4. Com organitzar el procés de treball paral·lel en un projecte per part de diversos desenvolupadors
5. Com implementar de manera segura més canvis a l'estructura de la base de dades en un entorn de producció
   

   SchemaKeeper dissenyat per treballar amb procediments emmagatzemats escrits en l'idioma PL/pgSQL. No s'han realitzat proves amb altres idiomes, per la qual cosa és possible que l'ús no sigui tan efectiu o no sigui possible.

Com emmagatzemar un abocament d'estructura de base de dades a VCS

Biblioteca responsable d'esquemes proporciona una funció saveDump, que desa l'estructura de tots els objectes de la base de dades com a fitxers de text separats. La sortida és un directori que conté l'estructura de la base de dades, dividida en fitxers agrupats que es poden afegir fàcilment a VCS.

Vegem com convertir objectes d'una base de dades en fitxers utilitzant diversos exemples:

Tipus d'objecte
L'esquema
Nom
Camí relatiu al fitxer

taula
públic
comptes
./public/tables/accounts.txt

Procediment emmagatzemat
públic
auth (hash bigint)
./public/functions/auth(int8).sql

Introducció
reserva
tarifes
./booking/views/tariffs.txt

El contingut dels fitxers és una representació textual de l'estructura d'un objecte de base de dades específic. Per exemple, per als procediments emmagatzemats, el contingut del fitxer serà la definició completa del procediment emmagatzemat, començant pel bloc CREATE OR REPLACE FUNCTION.

Com es pot veure a la taula anterior, el camí al fitxer emmagatzema informació sobre el tipus, l'esquema i el nom de l'objecte. Aquest enfocament facilita la navegació per l'abocament i la revisió del codi dels canvis a la base de dades.

extensió .sql per als fitxers amb codi font de procediment emmagatzemat, es va seleccionar perquè l'IDE proporcioni automàticament eines per interactuar amb la base de dades quan s'obre el fitxer.

Com fer el seguiment dels canvis a l'estructura de la base de dades després de desar un bolcat

En desar un abocament de l'estructura de la base de dades actual a VCS, tenim l'oportunitat de comprovar si es van fer canvis a l'estructura de la base de dades després de crear l'abocament. A la biblioteca responsable d'esquemes per detectar canvis en l'estructura de la base de dades, es proporciona una funció verifyDump, que retorna informació sobre les diferències sense efectes secundaris.

Una forma alternativa de comprovar-ho és tornar a cridar la funció saveDump, especificant el mateix directori i comproveu si hi ha canvis a VCS. Com que tots els objectes de la base de dades es guarden en fitxers separats, VCS només mostrarà els objectes modificats.
El principal desavantatge d'aquest mètode és la necessitat de sobreescriure els fitxers per veure els canvis.

Com transferir els canvis a l'estructura de la base de dades a altres entorns sense conflictes i fitxers de migració gegants

Gràcies a la funció deployDump El codi font dels procediments emmagatzemats es pot editar exactament de la mateixa manera que el codi font normal de l'aplicació. Podeu afegir/suprimir noves línies al codi de procediment emmagatzemat i immediatament empènyer els canvis al control de versions, o crear/suprimir procediments emmagatzemats creant/suprimint els fitxers corresponents al directori d'abocament.

Per exemple, per crear un procediment emmagatzemat nou en un esquema public només cal que creeu un fitxer nou amb l'extensió .sql al directori public/functions, col·loqueu-hi el codi font del procediment emmagatzemat, inclòs el bloc CREATE OR REPLACE FUNCTION, llavors crida a la funció deployDump. La modificació i la supressió d'un procediment emmagatzemat es produeix de la mateixa manera. Així, el codi entra tant al VCS com a la base de dades alhora.

Si apareix un error al codi font de qualsevol procediment emmagatzemat, o una discrepància entre els noms del fitxer i el procediment emmagatzemat, aleshores deployDump fallarà, mostrant el text d'error. La manca de concordança dels procediments emmagatzemats entre l'abocament i la base de dades actual és impossible quan s'utilitza deployDump.

Quan es crea un procediment emmagatzemat nou, no cal introduir manualment el nom de fitxer correcte. N'hi ha prou que el fitxer tingui l'extensió .sql. Després de la trucada deployDump el text d'error contindrà el nom correcte, que es pot utilitzar per canviar el nom del fitxer.

deployDump permet canviar els paràmetres d'una funció o tipus de retorn sense accions addicionals, mentre que amb l'enfocament clàssic hauríeu de
executar primer DROP FUNCTION, i només llavors CREATE OR REPLACE FUNCTION.

Malauradament, hi ha algunes situacions en què deployDump no es poden aplicar canvis automàticament. Per exemple, si s'elimina una funció de disparador que fa servir almenys un disparador. Aquestes situacions es resolen manualment mitjançant fitxers de migració.

Si sou responsable de migrar els canvis als procediments emmagatzemats responsable d'esquemes, llavors els fitxers de migració s'han d'utilitzar per transferir altres canvis a l'estructura. Per exemple, una bona biblioteca per treballar amb migracions és doctrina/migracions.

Les migracions s'han d'aplicar abans del llançament deployDump. Això permet fer tots els canvis a l'estructura i resoldre situacions problemàtiques de manera que els canvis en els procediments emmagatzemats es transfereixin posteriorment sense problemes.

El treball amb migracions es descriu amb més detall a les seccions següents.

Com organitzar el procés de treball paral·lel en un projecte per part de diversos desenvolupadors

Cal crear un script per a la inicialització completa de la base de dades, que el desenvolupador llançarà a la seva màquina de treball, posant l'estructura de la base de dades local d'acord amb l'abocament desat a VCS. La manera més senzilla és dividir la inicialització de la base de dades local en 3 passos:

1. Importa un fitxer amb una estructura bàsica que s'anomenarà p. base.sql
2. Aplicació de les migracions
3. Desafiament deployDump

base.sql és el punt de partida sobre el qual s'apliquen i s'executen les migracions deployDumpAixò és, base.sql + миграции + deployDump = актуальная структура БД. Podeu crear aquest fitxer mitjançant la utilitat pg_dump. Usat base.sql exclusivament en inicialitzar la base de dades des de zero.

Anem a cridar l'script per a la inicialització completa de la base de dades refresh.sh. El flux de treball podria semblar a aquest:

1. El desenvolupador es llança al seu entorn refresh.sh i obté l'estructura actual de la base de dades
2. El desenvolupador comença a treballar en la tasca en qüestió, modificant la base de dades local per satisfer les necessitats de la nova funcionalitat (ALTER TABLE ... ADD COLUMN etc)
3. Després de completar la tasca, el desenvolupador crida a la funció saveDumpper confirmar els canvis fets a la base de dades a VCS
4. Relançament del desenvolupador refresh.sh, llavors verifyDumpque ara mostra una llista de canvis per incloure en la migració
5. El desenvolupador transfereix tots els canvis d'estructura al fitxer de migració i torna a executar-se refresh.sh и verifyDumpi, si la migració es compila correctament, verifyDump no mostrarà diferències entre la base de dades local i l'abocament desat

El procés descrit anteriorment és compatible amb els principis de gitflow. Cada branca del VCS contindrà la seva pròpia versió de l'abocador, i quan es fusionin branques, es fusionaran. En la majoria dels casos, no cal fer cap acció addicional després d'una fusió, però si es van fer canvis en diferents branques, per exemple, a la mateixa taula, pot sorgir un conflicte.

Considerem una situació de conflicte utilitzant un exemple: hi ha una branca desenvolupar, de la qual es ramifiquen dues branques: característica1 и característica2, amb els quals no hi ha conflictes desenvolupar, però tenen conflictes entre ells. La tasca és fusionar ambdues branques desenvolupar. En aquest cas, es recomana fusionar primer una de les branques desenvolupari després fusionar-se desenvolupar a la branca restant, resolent els conflictes a la branca restant i després fusionant l'última branca desenvolupar. Durant la fase de resolució de conflictes, és possible que hàgiu d'arreglar el fitxer de migració a l'última branca perquè coincideixi amb el bolcat final, que inclou els resultats de les fusions.

Com implementar de manera segura més canvis a l'estructura de la base de dades en un entorn de producció

Gràcies a la presència d'un abocament de l'estructura de la base de dades actual a VCS, és possible comprovar el compliment exacte de la base de dades de producció amb l'estructura requerida. Això garanteix que tots els canvis que pretenien els desenvolupadors es van transferir amb èxit a la base de producció.

Com DDL a PostgreSQL és transaccional, es recomana complir l'ordre de desplegament següent, de manera que, en cas d'error inesperat, pugueu executar-lo "sense dolor" ROLLBACK:

1. Inicia la transacció
2. Realitzeu totes les migracions en una transacció
3. En la mateixa transacció, executar deployDump
4. Sense completar la transacció, executeu verifyDump. Si no hi ha errors, executeu COMMIT. Si hi ha errors, executeu ROLLBACK

Aquests passos es poden integrar fàcilment en els enfocaments existents per al desplegament d'aplicacions, inclòs el temps d'inactivitat zero.

Conclusió

Gràcies als mètodes descrits anteriorment, és possible extreure el màxim rendiment dels projectes "PHP + PostgreSQL", alhora que es sacrifica relativament poca comoditat de desenvolupament en comparació amb la implementació de tota la lògica empresarial al codi de l'aplicació principal. A més, el tractament de dades en PL/pgSQL sovint sembla més transparent i requereix menys codi que la mateixa funcionalitat escrita en PHP.

Font: www.habr.com