O propósito deste artigo é utilizar o exemplo dunha biblioteca mostrar ferramentas que poden simplificar significativamente o proceso de desenvolvemento de bases de datos dentro de proxectos PHP usando o DBMS PostgreSQL.
A información deste artigo será, en primeiro lugar, útil para os desenvolvedores que queiran aproveitar ao máximo as capacidades de PostgreSQL, pero que se enfrontan a problemas para manter a lóxica empresarial colocada na base de datos.
Este artigo non describirá as vantaxes ou desvantaxes de almacenar a lóxica empresarial nunha base de datos. Suponse que a elección xa foi feita polo lector.
Consideraranse as seguintes preguntas:
- En que forma debería almacenarse un volcado de estrutura de base de datos nun sistema de control de versións (en diante denominado VCS)
- Como rastrexar os cambios na estrutura da base de datos despois de gardar un volcado
- Como transferir os cambios na estrutura da base de datos a outros ambientes sen conflitos e ficheiros de migración xigantes
- Como organizar o proceso de traballo paralelo nun proxecto por parte de varios desenvolvedores
- Como implementar de forma segura máis cambios na estrutura da base de datos nun ambiente de produción
SchemaKeeper deseñado para traballar con procedementos almacenados escritos na lingua . Non se realizaron probas con outros idiomas, polo que é posible que o seu uso non sexa tan eficaz ou non sexa posible.
Como almacenar un volcado de estrutura de base de datos en VCS
biblioteca proporciona unha función saveDump, que garda a estrutura de todos os obxectos da base de datos como ficheiros de texto separados. A saída é un directorio que contén a estrutura da base de datos, dividida en ficheiros agrupados que se poden engadir facilmente a VCS.
Vexamos como converter obxectos dunha base de datos en ficheiros usando varios exemplos:
Tipo de obxecto
O esquema
nome
Ruta relativa ao ficheiro
mesa
público
contas
./public/tables/accounts.txt
Procedemento almacenado
público
auth (hash bigint)
./public/functions/auth(int8).sql
Introdución
reserva
tarifas
./booking/views/tariffs.txt
O contido dos ficheiros é unha representación textual da estrutura dun obxecto de base de datos específico. Por exemplo, para os procedementos almacenados, o contido do ficheiro será a definición completa do procedemento almacenado, comezando polo bloque CREATE OR REPLACE FUNCTION.
Como se pode ver na táboa anterior, o camiño ao ficheiro almacena información sobre o tipo, esquema e nome do obxecto. Este enfoque fai máis doado navegar polo volcado e a revisión do código dos cambios na base de datos.
extensión
.sqlpara ficheiros con código fonte de procedemento almacenado, seleccionouse para que o IDE fornece automaticamente ferramentas para interactuar coa base de datos cando se abre o ficheiro.
Como rastrexar os cambios na estrutura da base de datos despois de gardar un volcado
Ao gardar un volcado da estrutura da base de datos actual en VCS, temos a oportunidade de comprobar se se fixeron cambios na estrutura da base de datos despois de que se crease o volcado. Na biblioteca para detectar cambios na estrutura da base de datos, ofrécese unha función verifyDump, que devolve información sobre as diferenzas sen efectos secundarios.
Unha forma alternativa de comprobar é chamar de novo á función saveDump, especificando o mesmo directorio e comprobe os cambios no VCS. Dado que todos os obxectos da base de datos gárdanse en ficheiros separados, o VCS só mostrará os obxectos modificados.
A principal desvantaxe deste método é a necesidade de sobrescribir os ficheiros para ver os cambios.
Como transferir os cambios na estrutura da base de datos a outros ambientes sen conflitos e ficheiros de migración xigantes
Grazas á función deployDump O código fonte dos procedementos almacenados pódese editar exactamente do mesmo xeito que o código fonte normal da aplicación. Podes engadir/eliminar novas liñas no código do procedemento almacenado e introducir inmediatamente os cambios no control de versión, ou crear/eliminar procedementos almacenados creando/eliminando os ficheiros correspondentes no directorio de volcado.
Por exemplo, para crear un novo procedemento almacenado nun esquema public basta con crear un novo ficheiro coa extensión .sql no directorio public/functions, coloca nel o código fonte do procedemento almacenado, incluído o bloque CREATE OR REPLACE FUNCTION, entón chame á función deployDump. A modificación e a eliminación dun procedemento almacenado ocorre do mesmo xeito. Así, o código entra tanto no VCS como na base de datos ao mesmo tempo.
Se aparece un erro no código fonte de calquera procedemento almacenado ou unha discrepancia entre os nomes do ficheiro e o procedemento almacenado, entón deployDump fallará, mostrando texto de erro. A falta de coincidencia dos procedementos almacenados entre o volcado e a base de datos actual é imposible cando se usa deployDump.
Ao crear un novo procedemento almacenado, non é necesario introducir manualmente o nome de ficheiro correcto. É suficiente que o ficheiro teña a extensión
.sql. Despois da chamadadeployDumpo texto do erro conterá o nome correcto, que se pode usar para renomear o ficheiro.
deployDump permítelle cambiar os parámetros dunha función ou tipo de retorno sen accións adicionais, mentres que co enfoque clásico tería que
executar primeiro DROP FUNCTION, e só entón CREATE OR REPLACE FUNCTION.
Desafortunadamente, hai algunhas situacións nas que deployDump non se poden aplicar cambios automaticamente. Por exemplo, se elimina unha función de disparo que é utilizada polo menos por un disparador. Tales situacións resólvense manualmente mediante ficheiros de migración.
Se es responsable de migrar os cambios aos procedementos almacenados , entón os ficheiros de migración deben usarse para transferir outros cambios na estrutura. Por exemplo, unha boa biblioteca para traballar con migracións é .
As migracións deben aplicarse antes do lanzamento deployDump. Isto permítelle facer todos os cambios na estrutura e resolver situacións problemáticas para que os cambios nos procedementos almacenados sexan posteriormente transferidos sen problemas.
O traballo con migracións describirase con máis detalle nas seguintes seccións.
Como organizar o proceso de traballo paralelo nun proxecto por parte de varios desenvolvedores
É necesario crear un script para a inicialización completa da base de datos, que será lanzado polo programador na súa máquina de traballo, axustando a estrutura da base de datos local ao volcado gardado en VCS. O xeito máis sinxelo é dividir a inicialización da base de datos local en 3 pasos:
- Importar un ficheiro cunha estrutura básica que se chamará, p.
base.sql - Aplicación de Migracións
- Chamar
deployDump
base.sqlé o punto de partida sobre o cal se aplican e executan as migraciónsdeployDumpÉ dicir,base.sql + миграции + deployDump = актуальная структура БД. Podes crear tal ficheiro usando a utilidadepg_dump. Usadobase.sqlexclusivamente ao inicializar a base de datos desde cero.
Chamemos ao script para a inicialización completa da base de datos refresh.sh. O fluxo de traballo pode verse así:
- O desenvolvedor lánzase no seu entorno
refresh.she obtén a estrutura da base de datos actual - O desenvolvedor comeza a traballar na tarefa en cuestión, modificando a base de datos local para satisfacer as necesidades da nova funcionalidade (
ALTER TABLE ... ADD COLUMNetc) - Despois de completar a tarefa, o programador chama a función
saveDumppara confirmar os cambios realizados na base de datos en VCS - Relanzamento do programador
refresh.sh, entónverifyDumpque agora mostra unha lista de cambios para incluír na migración - O programador transfire todos os cambios de estrutura ao ficheiro de migración e execútase de novo
refresh.shиverifyDumpe, se a migración se compila correctamente,verifyDumpnon mostrará diferenzas entre a base de datos local e o volcado gardado
O proceso descrito anteriormente é compatible cos principios de gitflow. Cada rama do VCS conterá a súa propia versión do vertedoiro e, ao combinar ramas, fusionaranse. Na maioría dos casos, non é necesario realizar ningunha acción adicional despois dunha fusión, pero se se fixeron cambios en ramas diferentes, por exemplo, na mesma táboa, pode xurdir un conflito.
Consideremos unha situación de conflito usando un exemplo: hai unha rama desenvolver, da que parten dúas ramas: característica1 и característica2, que non teñen conflitos desenvolver, pero teñen conflitos entre eles. A tarefa é fusionar ambas ramas desenvolver. Para este caso, recoméndase fusionar primeiro unha das ramas desenvolvere despois fusionar desenvolver á rama restante, resolvendo conflitos na rama restante e, a continuación, fusionando a última rama desenvolver. Durante a fase de resolución de conflitos, pode ter que arranxar o ficheiro de migración na última rama para que coincida co volcado final, que inclúe os resultados das fusións.
Como implementar de forma segura máis cambios na estrutura da base de datos nun ambiente de produción
Grazas á presenza dun volcado da estrutura da base de datos actual en VCS, faise posible comprobar a base de datos de produción para o cumprimento exacto da estrutura requirida. Isto garante que todos os cambios que pretendían os desenvolvedores foron transferidos con éxito á base de produción.
Como en PostgreSQL é , recoméndase cumprir a seguinte orde de despregamento, para que, en caso de erro inesperado, poida executar "sen dor" ROLLBACK:
- Iniciar transacción
- Realiza todas as migracións nunha transacción
- Na mesma transacción, executa
deployDump - Sen completar a transacción, executa
verifyDump. Se non hai erros, executaCOMMIT. Se hai erros, executaROLLBACK
Estes pasos pódense integrar facilmente nos enfoques existentes para a implantación de aplicacións, incluído o tempo de inactividade cero.
Conclusión
Grazas aos métodos descritos anteriormente, é posible espremer o máximo rendemento dos proxectos "PHP + PostgreSQL", sacrificando relativamente pouca comodidade de desenvolvemento en comparación coa implementación de toda a lóxica empresarial no código da aplicación principal. Ademais, o tratamento de datos en moitas veces parece máis transparente e require menos código que a mesma funcionalidade escrita en PHP.
Fonte: www.habr.com