Le but de cet article est d'utiliser l'exemple d'une bibliothèque gardien de schéma présente des outils qui peuvent simplifier considérablement le processus de développement de bases de données au sein de projets PHP à l'aide du SGBD PostgreSQL.

Les informations contenues dans cet article seront tout d'abord utiles aux développeurs qui souhaitent tirer le meilleur parti des fonctionnalités de PostgreSQL, mais qui sont confrontés à des problèmes de maintenance de la logique métier placée dans la base de données.

Cet article ne décrira pas les avantages ou les inconvénients du stockage de la logique métier dans une base de données. On suppose que le choix a déjà été fait par le lecteur.

Les questions suivantes seront examinées :

Sous quelle forme un dump de structure de base de données doit-il être stocké dans un système de contrôle de version (ci-après dénommé VCS)
Comment suivre les modifications dans la structure de la base de données après avoir enregistré un dump
Comment transférer les modifications de la structure de la base de données vers d'autres environnements sans conflits ni fichiers de migration géants
Comment organiser le processus de travail parallèle sur un projet par plusieurs développeurs
Comment déployer en toute sécurité davantage de modifications dans la structure de la base de données dans un environnement de production

Gardien de schéma conçu pour travailler avec des procédures stockées écrites dans le langage PL / pgSQL. Les tests avec d'autres langues n'ont pas été effectués, son utilisation peut donc ne pas être aussi efficace ou ne pas être possible.

Comment stocker un dump de structure de base de données dans VCS

bibliothèque gardien de schéma fournit une fonction saveDump, qui enregistre la structure de tous les objets de la base de données sous forme de fichiers texte distincts. La sortie est un répertoire contenant la structure de la base de données, divisée en fichiers groupés qui peuvent être facilement ajoutés à VCS.

Examinons la conversion d'objets d'une base de données en fichiers à l'aide de plusieurs exemples :

Type d'objet
Conduire
Nom
Chemin relatif au fichier

Таблица
public
comptes
./public/tables/accounts.txt

Procédure stockée
public
auth (hachage bigint)
./public/functions/auth(int8).sql

Introduction
Réserver
tarifs
./booking/views/tariffs.txt

Le contenu des fichiers est une représentation textuelle de la structure d'un objet de base de données spécifique. Par exemple, pour les procédures stockées, le contenu du fichier sera la définition complète de la procédure stockée, en commençant par le bloc CREATE OR REPLACE FUNCTION.

Comme le montre le tableau ci-dessus, le chemin d'accès au fichier stocke des informations sur le type, le schéma et le nom de l'objet. Cette approche facilite la navigation dans le dump et la révision du code des modifications apportées à la base de données.

extension .sql pour les fichiers avec le code source d'une procédure stockée, cette option a été sélectionnée afin que l'EDI fournisse automatiquement des outils pour interagir avec la base de données lors de l'ouverture du fichier.

Comment suivre les modifications dans la structure de la base de données après avoir enregistré un dump

En enregistrant un dump de la structure actuelle de la base de données dans VCS, nous avons la possibilité de vérifier si des modifications ont été apportées à la structure de la base de données après la création du dump. En librairie gardien de schéma pour détecter les changements dans la structure de la base de données, une fonction est fournie verifyDump, qui renvoie des informations sur les différences sans effets secondaires.

Une autre façon de vérifier est d'appeler à nouveau la fonction saveDump, en spécifiant le même répertoire, et vérifiez les modifications dans VCS. Étant donné que tous les objets de la base de données sont enregistrés dans des fichiers séparés, VCS affichera uniquement les objets modifiés.
Le principal inconvénient de cette méthode est la nécessité d’écraser les fichiers pour voir les modifications.

Comment transférer les modifications de la structure de la base de données vers d'autres environnements sans conflits ni fichiers de migration géants

Grâce à la fonction deployDump Le code source des procédures stockées peut être modifié exactement de la même manière que le code source d'une application standard. Vous pouvez ajouter/supprimer de nouvelles lignes dans le code de la procédure stockée et appliquer immédiatement les modifications au contrôle de version, ou créer/supprimer des procédures stockées en créant/supprimant les fichiers correspondants dans le répertoire de vidage.

Par exemple, pour créer une nouvelle procédure stockée dans un schéma public créez simplement un nouveau fichier avec l'extension .sql dans le répertoire public/functions, placez-y le code source de la procédure stockée, y compris le bloc CREATE OR REPLACE FUNCTION, puis appelez la fonction deployDump. La modification et la suppression d'une procédure stockée s'effectuent de la même manière. Ainsi, le code entre à la fois dans le VCS et dans la base de données.

Si une erreur apparaît dans le code source d'une procédure stockée, ou une différence entre les noms du fichier et la procédure stockée, alors deployDump échouera, affichant un texte d’erreur. La non-concordance des procédures stockées entre le dump et la base de données actuelle est impossible lors de l'utilisation deployDump.

Lors de la création d'une nouvelle procédure stockée, il n'est pas nécessaire de saisir manuellement le nom de fichier correct. Il suffit que le fichier ait l'extension .sql. Après l'appel deployDump le texte d'erreur contiendra le nom correct, qui peut être utilisé pour renommer le fichier.

deployDump permet de modifier les paramètres d'une fonction ou d'un type de retour sans actions supplémentaires, alors qu'avec l'approche classique il faudrait
exécuter en premier DROP FUNCTION, et alors seulement CREATE OR REPLACE FUNCTION.

Malheureusement, il existe certaines situations où deployDump impossible d'appliquer automatiquement les modifications. Par exemple, si une fonction de déclencheur utilisée par au moins un déclencheur est supprimée. De telles situations sont résolues manuellement à l'aide de fichiers de migration.

Si vous êtes responsable de la migration des modifications vers les procédures stockées gardien de schéma, les fichiers de migration doivent alors être utilisés pour transférer d'autres modifications dans la structure. Par exemple, une bonne bibliothèque pour travailler avec les migrations est doctrine/migrations.

Les migrations doivent être appliquées avant le lancement deployDump. Cela vous permet d'apporter toutes les modifications à la structure et de résoudre les situations problématiques afin que les modifications des procédures stockées soient ensuite transférées sans problème.

L'utilisation des migrations sera décrite plus en détail dans les sections suivantes.

Comment organiser le processus de travail parallèle sur un projet par plusieurs développeurs

Il est nécessaire de créer un script pour l'initialisation complète de la base de données, qui sera lancé par le développeur sur sa machine de travail, mettant ainsi la structure de la base de données locale en conformité avec le dump enregistré dans VCS. Le plus simple est de diviser l’initialisation de la base de données locale en 3 étapes :

Importez un fichier avec une structure de base qui sera appelée par ex. base.sql
Application des migrations
Défi deployDump

base.sql est le point de départ à partir duquel les migrations sont appliquées et exécutées deployDumpC'est-à- base.sql + миграции + deployDump = актуальная структура БД. Vous pouvez créer un tel fichier à l'aide de l'utilitaire pg_dump. utilisé base.sql exclusivement lors de l'initialisation de la base de données à partir de zéro.

Appelons le script pour l'initialisation complète de la base de données refresh.sh. Le flux de travail pourrait ressembler à ceci :

Le développeur se lance dans son environnement refresh.sh et obtient la structure actuelle de la base de données
Le développeur commence à travailler sur la tâche à accomplir, en modifiant la base de données locale pour répondre aux besoins de la nouvelle fonctionnalité (ALTER TABLE ... ADD COLUMN etc)
Après avoir terminé la tâche, le développeur appelle la fonction saveDumppour valider les modifications apportées à la base de données dans VCS
Relance du développeur refresh.shpuis verifyDumpqui affiche désormais une liste des modifications à inclure dans la migration
Le développeur transfère toutes les modifications de structure dans le fichier de migration et exécute à nouveau refresh.sh и verifyDump, et, si la migration est compilée correctement, verifyDump ne montrera aucune différence entre la base de données locale et le dump enregistré

Le processus décrit ci-dessus est compatible avec les principes de gitflow. Chaque branche du VCS contiendra sa propre version du dump, et lors de la fusion des branches, les dumps seront fusionnés. Dans la plupart des cas, aucune action supplémentaire n'est nécessaire après une fusion, mais si des modifications ont été apportées dans différentes branches, par exemple dans la même table, un conflit peut survenir.

Considérons une situation de conflit à l'aide d'un exemple : il y a une branche développer, d'où partent deux branches : feature1 и feature2, qui n'ont aucun conflit avec développer, mais sont en conflit les uns avec les autres. La tâche consiste à fusionner les deux branches en développer. Dans ce cas, il est recommandé de fusionner d'abord l'une des branches dans développerpuis fusionner développer à la branche restante, en résolvant les conflits dans la branche restante, puis en fusionnant la dernière branche dans développer. Lors de la phase de résolution des conflits, vous devrez peut-être corriger le fichier de migration dans la dernière branche afin qu'il corresponde au dump final, qui inclut les résultats des fusions.

Comment déployer en toute sécurité davantage de modifications dans la structure de la base de données dans un environnement de production

Grâce à la présence d'un dump de la structure actuelle de la base de données dans VCS, il devient possible de vérifier la conformité exacte de la base de données de production avec la structure requise. Cela garantit que tous les changements prévus par les développeurs ont été transférés avec succès vers la base de production.

depuis DDL dans PostgreSQL est transactionnel, il est recommandé de respecter l'ordre de déploiement suivant, afin qu'en cas d'erreur inattendue, vous puissiez exécuter « sans douleur » ROLLBACK:

Commencer la transaction
Effectuer toutes les migrations dans une transaction
Dans la même transaction, exécutez deployDump
Sans terminer la transaction, exécutez verifyDump. S'il n'y a pas d'erreur, exécutez COMMIT. S'il y a des erreurs, exécutez ROLLBACK

Ces étapes peuvent être facilement intégrées aux approches existantes de déploiement d’applications, y compris l’absence de temps d’arrêt.

Conclusion

Grâce aux méthodes décrites ci-dessus, il est possible d'optimiser les performances des projets « PHP + PostgreSQL », tout en sacrifiant relativement peu de commodité de développement par rapport à l'implémentation de toute la logique métier dans le code de l'application principale. De plus, le traitement des données dans PL / pgSQL semble souvent plus transparent et nécessite moins de code que la même fonctionnalité écrite en PHP.

Source: habr.com

Logique métier dans la base de données à l'aide de SchemaKeeper