El propósito de este artículo es utilizar el ejemplo de una biblioteca. guardián del esquema muestre herramientas que pueden simplificar significativamente el proceso de desarrollo de bases de datos dentro de proyectos PHP utilizando el DBMS PostgreSQL.

La información de este artículo será, en primer lugar, útil para los desarrolladores que quieran aprovechar al máximo las capacidades de PostgreSQL, pero se enfrentan a problemas para mantener la lógica empresarial colocada en la base de datos.

Este artículo no describirá las ventajas o desventajas de almacenar la lógica empresarial en una base de datos. Se supone que el lector ya ha hecho la elección.

Se considerarán las siguientes preguntas:

1. ¿De qué forma se debe almacenar un volcado de estructura de base de datos en un sistema de control de versiones (en adelante, VCS)?
2. Cómo realizar un seguimiento de los cambios en la estructura de la base de datos después de guardar un volcado
3. Cómo transferir cambios en la estructura de la base de datos a otros entornos sin conflictos ni archivos de migración gigantes
4. Cómo organizar el proceso de trabajo paralelo en un proyecto por parte de varios desarrolladores
5. Cómo implementar de forma segura más cambios en la estructura de la base de datos en un entorno de producción
   

   Guardián del esquema diseñado para trabajar con procedimientos almacenados escritos en el lenguaje PL / pgSQL. No se han realizado pruebas con otros idiomas, por lo que su uso puede no ser tan efectivo o no ser posible.

Cómo almacenar un volcado de estructura de base de datos en VCS

Biblioteca guardián del esquema proporciona una función saveDump, que guarda la estructura de todos los objetos de la base de datos como archivos de texto separados. El resultado es un directorio que contiene la estructura de la base de datos, dividida en archivos agrupados que se pueden agregar fácilmente a VCS.

Veamos cómo convertir objetos de una base de datos en archivos usando varios ejemplos:

Tipo de objeto
esquema
nombre
Ruta relativa al archivo

Таблица
público
cuentas
./public/tables/accounts.txt

Procedimiento almacenado
público
autenticación (hash bigint)
./public/functions/auth(int8).sql

Introducción
Booking
Tarifas
./booking/views/tariffs.txt

El contenido de los archivos es una representación textual de la estructura de un objeto de base de datos específico. Por ejemplo, para procedimientos almacenados, el contenido del archivo será la definición completa del procedimiento almacenado, comenzando con el bloque CREATE OR REPLACE FUNCTION.

Como puede verse en la tabla anterior, la ruta al archivo almacena información sobre el tipo, esquema y nombre del objeto. Este enfoque facilita la navegación a través del volcado y la revisión del código de los cambios en la base de datos.

extensión .sql para archivos con código fuente de procedimiento almacenado, esto se seleccionó para que el IDE proporcione automáticamente herramientas para interactuar con la base de datos cuando se abre el archivo.

Cómo realizar un seguimiento de los cambios en la estructura de la base de datos después de guardar un volcado

Al guardar un volcado de la estructura de la base de datos actual en VCS, tenemos la oportunidad de verificar si se realizaron cambios en la estructura de la base de datos después de que se creó el volcado. En biblioteca guardián del esquema para detectar cambios en la estructura de la base de datos, se proporciona una función verifyDump, que devuelve información sobre las diferencias sin efectos secundarios.

Una forma alternativa de comprobarlo es llamar a la función nuevamente. saveDump, especificando el mismo directorio y verifique los cambios en VCS. Dado que todos los objetos de la base de datos se guardan en archivos separados, VCS solo mostrará los objetos modificados.
La principal desventaja de este método es la necesidad de sobrescribir archivos para poder ver los cambios.

Cómo transferir cambios en la estructura de la base de datos a otros entornos sin conflictos ni archivos de migración gigantes

Gracias a la función deployDump El código fuente de los procedimientos almacenados se puede editar exactamente de la misma manera que el código fuente de una aplicación normal. Puede agregar/eliminar nuevas líneas en el código del procedimiento almacenado e inmediatamente enviar cambios al control de versiones, o crear/eliminar procedimientos almacenados creando/eliminando los archivos correspondientes en el directorio de volcado.

Por ejemplo, para crear un nuevo procedimiento almacenado en un esquema public simplemente crea un nuevo archivo con la extensión .sql en el directorio public/functions, coloque en él el código fuente del procedimiento almacenado, incluido el bloque CREATE OR REPLACE FUNCTION, luego llama a la función deployDump. La modificación y eliminación de un procedimiento almacenado se produce de la misma manera. Por lo tanto, el código ingresa tanto al VCS como a la base de datos al mismo tiempo.

Si aparece un error en el código fuente de cualquier procedimiento almacenado, o una discrepancia entre los nombres del archivo y el procedimiento almacenado, entonces deployDump fallará y mostrará un texto de error. La falta de coincidencia de los procedimientos almacenados entre el volcado y la base de datos actual es imposible cuando se usa deployDump.

Al crear un nuevo procedimiento almacenado, no es necesario ingresar manualmente el nombre de archivo correcto. Basta con que el archivo tenga la extensión .sql. despues de la llamada deployDump el texto de error contendrá el nombre correcto, que se puede utilizar para cambiar el nombre del archivo.

deployDump le permite cambiar los parámetros de una función o tipo de retorno sin acciones adicionales, mientras que con el enfoque clásico tendría que
ejecutar primero DROP FUNCTION, y solo entonces CREATE OR REPLACE FUNCTION.

Desafortunadamente, hay algunas situaciones en las que deployDump No se pueden aplicar los cambios automáticamente. Por ejemplo, si se elimina una función de activador utilizada por al menos un activador. Estas situaciones se resuelven manualmente mediante archivos de migración.

Si es responsable de migrar los cambios a los procedimientos almacenados guardián del esquema, entonces los archivos de migración deben usarse para transferir otros cambios en la estructura. Por ejemplo, una buena biblioteca para trabajar con migraciones es doctrina/migraciones.

Las migraciones deben aplicarse antes del lanzamiento. deployDump. Esto le permite realizar todos los cambios en la estructura y resolver situaciones problemáticas para que los cambios en los procedimientos almacenados se transfieran posteriormente sin problemas.

El trabajo con migraciones se describirá con más detalle en las siguientes secciones.

Cómo organizar el proceso de trabajo paralelo en un proyecto por parte de varios desarrolladores

Es necesario crear un script para la inicialización completa de la base de datos, que será ejecutado por el desarrollador en su máquina de trabajo, adaptando la estructura de la base de datos local al volcado guardado en VCS. La forma más sencilla es dividir la inicialización de la base de datos local en 3 pasos:

1. Importe un archivo con una estructura básica que se llamará, p.e. base.sql
2. Aplicar migraciones
3. Llamar deployDump

base.sql es el punto de partida sobre el cual se aplican y ejecutan las migraciones deployDumpes decir, base.sql + миграции + deployDump = актуальная структура БД. Puede crear dicho archivo usando la utilidad pg_dump. usado base.sql exclusivamente al inicializar la base de datos desde cero.

Llamemos al script para la inicialización completa de la base de datos. refresh.sh. El flujo de trabajo podría verse así:

1. El desarrollador lanza en su entorno. refresh.sh y obtiene la estructura de la base de datos actual
2. El desarrollador comienza a trabajar en la tarea en cuestión, modificando la base de datos local para satisfacer las necesidades de la nueva funcionalidad (ALTER TABLE ... ADD COLUMN y así sucesivamente)
3. Después de completar la tarea, el desarrollador llama a la función. saveDumppara confirmar los cambios realizados en la base de datos en VCS
4. Relanzamiento del desarrollador refresh.shentonces verifyDumpque ahora muestra una lista de cambios para incluir en la migración
5. El desarrollador transfiere todo el cambio de estructura al archivo de migración y lo ejecuta nuevamente refresh.sh и verifyDumpy, si la migración se compila correctamente, verifyDump no mostrará diferencias entre la base de datos local y el volcado guardado

El proceso descrito anteriormente es compatible con los principios de gitflow. Cada rama en el VCS contendrá su propia versión del volcado y, al fusionar ramas, los volcados se fusionarán. En la mayoría de los casos, no es necesario realizar ninguna acción adicional después de una fusión, pero si se realizaron cambios en diferentes ramas, por ejemplo, en la misma tabla, puede surgir un conflicto.

Consideremos una situación de conflicto usando un ejemplo: hay una rama desarrollar, de donde se ramifican dos ramas: feature1 и feature2, que no tienen conflictos con desarrollar, pero tienen conflictos entre sí. La tarea es fusionar ambas ramas en desarrollar. Para este caso, se recomienda fusionar primero una de las ramas en desarrollary luego fusionar desarrollar a la rama restante, resolviendo conflictos en la rama restante y luego fusionando la última rama en desarrollar. Durante la fase de resolución de conflictos, es posible que tengas que arreglar el archivo de migración en la última rama para que coincida con el volcado final, que incluye los resultados de las fusiones.

Cómo implementar de forma segura más cambios en la estructura de la base de datos en un entorno de producción

Gracias a la presencia de un volcado de la estructura de la base de datos actual en VCS, es posible verificar que la base de datos de producción cumpla exactamente con la estructura requerida. Esto garantiza que todos los cambios que pretendían los desarrolladores se transfirieran con éxito a la base de producción.

desde DDL en PostgreSQL es transaccional, se recomienda seguir el siguiente orden de implementación, de modo que, en caso de un error inesperado, pueda ejecutar "sin complicaciones" ROLLBACK:

1. Iniciar transacción
2. Realizar todas las migraciones en una transacción
3. En la misma transacción, ejecute deployDump
4. Sin completar la transacción, ejecute verifyDump. Si no hay errores, ejecute COMMIT. Si hay errores, ejecute ROLLBACK

Estos pasos se pueden integrar fácilmente en los enfoques existentes para la implementación de aplicaciones, incluido el tiempo de inactividad cero.

Conclusión

Gracias a los métodos descritos anteriormente, es posible obtener el máximo rendimiento de los proyectos “PHP + PostgreSQL”, sacrificando relativamente poca comodidad de desarrollo en comparación con la implementación de toda la lógica empresarial en el código principal de la aplicación. Además, el procesamiento de datos en PL / pgSQL a menudo parece más transparente y requiere menos código que la misma funcionalidad escrita en PHP.

Fuente: habr.com