Ziel dieses Artikels ist es, anhand der Bibliothek schema-keeper Werkzeuge vorzustellen, die den Entwicklungsprozess von Datenbanken in PHP-Projekten, die PostgreSQL verwenden, erheblich erleichtern können.

Die Informationen in diesem Artikel sind vor allem für Entwickler nützlich, die die Möglichkeiten von PostgreSQL maximal ausschöpfen möchten, jedoch auf Herausforderungen bei der Pflege der in die Datenbank ausgelagerten Geschäftslogik stoßen.

Der Artikel wird die Vor- und Nachteile der Speicherung von Geschäftslogik in der Datenbank nicht beschreiben. Es wird davon ausgegangen, dass die Wahl bereits vom Leser getroffen wurde.

Folgende Fragen werden behandelt:

1. In welchem Format sollen Datenbank-Dumpstrukturen im Versionskontrollsystem (im Folgenden VCS) gespeichert werden?
2. Wie lassen sich Änderungen in der Datenbankstruktur nach dem Speichern des Dumps verfolgen?
3. Wie überträgt man Änderungen in der Datenbankstruktur ohne Konflikte und große Migrationsdateien auf andere Umgebungen?
4. Wie kann der Prozess der parallelen Zusammenarbeit mehrerer Entwickler am Projekt organisiert werden?
5. Wie können mehrere Änderungen in der Datenbankstruktur sicher in die Produktionsumgebung deployed werden?
   

   SchemaKeeper ist auf die Arbeit mit gespeicherten Prozeduren ausgelegt, die in der Sprache PL/pgSQL. Tests mit anderen Sprachen wurden nicht durchgeführt, daher kann die Verwendung weniger effektiv oder sogar unmöglich sein.

In welcher Form sollten Sie den Dump der Datenbankstruktur in VCS speichern?

Die Bibliothek schema-keeper bietet die Funktion saveDump, die die Struktur aller Objekte aus der Datenbank in Form einzelner Textdateien speichert. Am Ende wird ein Verzeichnis erstellt, das die Datenbankstruktur enthält, unterteilt in gruppierte Dateien, die leicht in VCS hinzugefügt werden können.

Betrachten wir die Umwandlung von Objekten aus der Datenbank in Dateien anhand mehrerer Beispiele:

Objekttyp
Schema
Titel
Relativer Pfad zur Datei

Tabelle
public
accounts
./public/tables/accounts.txt

Gespeicherte Prozedur
public
auth(hash bigint)
./public/functions/auth(int8).sql

Darstellung
booking
tariffs
./booking/views/tariffs.txt

Der Inhalt der Dateien ist eine textuelle Darstellung der Struktur eines bestimmten Datenbankobjekts. Zum Beispiel wird der Inhalt für gespeicherte Prozeduren die vollständige Definition der gespeicherten Prozedur enthalten, beginnend mit dem Block CREATE OR REPLACE FUNCTION.

Wie aus der obigen Tabelle ersichtlich ist, enthält der Dateipfad Informationen über den Typ, das Schema und den Namen des Objekts. Dieser Ansatz erleichtert die Navigation durch den Dump und die Überprüfung von Änderungen in der Datenbank.

Erweiterung .sql Für Dateien mit dem Quellcode von Stored Procedures wurde ausgewählt, damit die IDE automatisch Werkzeuge für die Interaktion mit der Datenbank beim Öffnen der Datei bereitstellt.

Wie lassen sich Änderungen in der Datenbankstruktur nach dem Speichern des Dumps verfolgen?

Indem wir ein Dump der aktuellen Struktur der Datenbank in VCS speichern, erhalten wir die Möglichkeit, zu überprüfen, ob Änderungen an der Struktur der Datenbank nach der Erstellung des Dumps vorgenommen wurden. In der Bibliothek schema-keeper gibt es eine Funktion zur Erkennung von Änderungen in der Struktur der Datenbank. verifyDump, die ohne Nebenwirkungen Informationen über die Unterschiede zurückgibt.

Eine alternative Methode zur Überprüfung besteht darin, die Funktion erneut aufzurufen, saveDump, wobei dasselbe Verzeichnis angegeben wird, und im VCS nach Änderungen zu suchen. Da alle Objekte aus der Datenbank in separaten Dateien gespeichert sind, zeigt das VCS nur die geänderten Objekte an.
Der Hauptnachteil dieser Methode ist die Notwendigkeit, die Dateien zu überschreiben, um Änderungen zu sehen.

Wie überträgt man Änderungen in der Datenbankstruktur ohne Konflikte und große Migrationsdateien auf andere Umgebungen?

Dank der Funktion deployDump Der Quellcode gespeicherter Prozeduren kann genau wie der normale Anwendungscode bearbeitet werden. Man kann neue Zeilen im Code gespeicherter Prozeduren hinzufügen oder entfernen und die Änderungen sofort ins Versionskontrollsystem übermitteln oder gespeicherte Prozeduren durch das Erstellen oder Löschen der entsprechenden Dateien im Dump-Verzeichnis erstellen oder entfernen.

Um beispielsweise eine neue gespeicherte Prozedur im Schema zu erstellen, public genügt es, eine neue Datei mit der Endung .sql wird im Verzeichnis public/functionszu erstellen, den Quellcode der gespeicherten Prozedur einschließlich des Blocks CREATE OR REPLACE FUNCTIONeinzufügen, und dann die Funktion deployDumpaufzurufen. Ebenso erfolgt die Änderung und Löschung der gespeicherten Prozedur. Auf diese Weise gelangt der Code gleichzeitig ins VCS und in die Datenbank.

Wenn im Quellcode einer gespeicherten Prozedur ein Fehler auftritt oder eine Unstimmigkeit zwischen dem Dateinamen und der gespeicherten Prozedur besteht, wird deployDump nicht ausgeführt und zeigt eine Fehlermeldung an. Eine Disparität zwischen den gespeicherten Prozeduren im Dump und der aktuellen Datenbank ist bei Verwendung von deployDump.

nicht möglich. Bei der Erstellung einer neuen gespeicherten Prozedur ist es nicht notwendig, den richtigen Dateinamen manuell einzugeben. Es reicht aus, dass die Datei die Endung .sql. Nach dem Aufruf deployDump wird die Fehlermeldung den korrekten Namen enthalten, der zum Umbenennen der Datei verwendet werden kann.

deployDump ermöglicht es, die Parameter der Funktion oder den Rückgabetyp ohne zusätzliche Schritte zu ändern, während man beim klassischen Ansatz zuerst
die Funktion ausführen musste DROP FUNCTION, und erst danach CREATE OR REPLACE FUNCTION.

Leider gibt es einige Situationen, in denen deployDump Änderungen nicht automatisch angewendet werden können. Zum Beispiel, wenn eine Triggerfunktion gelöscht wird, die von mindestens einem Trigger verwendet wird. Solche Situationen müssen manuell mit Migrationsdateien gelöst werden.

Wenn der Transfer von Änderungen in gespeicherten Prozeduren selbst schema-keeper, dann müssen Migrationsdateien verwendet werden, um andere Änderungen in der Struktur zu übertragen. Eine gute Bibliothek für die Arbeit mit Migrationen ist doctrine/migrations.

Migrationen müssen vor dem Ausführen angewendet werden deployDump. Dadurch können alle Änderungen an der Struktur vorgenommen und problematische Situationen gelöst werden, sodass die Änderungen in den gespeicherten Prozeduren später problemlos übertragen werden können.

Die Arbeit mit Migrationen wird in den folgenden Abschnitten ausführlicher beschrieben.

Wie kann der Prozess der parallelen Zusammenarbeit mehrerer Entwickler am Projekt organisiert werden?

Es ist notwendig, ein vollständiges Initialisierungsskript für die Datenbank zu erstellen, das vom Entwickler auf seinem Arbeitsrechner ausgeführt wird, um die Struktur der lokalen Datenbank mit dem im VCS gespeicherten Dump in Einklang zu bringen. Am einfachsten lässt sich die Initialisierung der lokalen Datenbank in 3 Schritte unterteilen:

1. Import der Datei mit der Basisstruktur, die beispielsweise genannt werden könnte base.sql
2. Anwendung von Migrationen
3. Aufruf deployDump

base.sql — das ist der Ausgangspunkt, über den die Migrationen angewendet werden und wo deployDump, das heißt base.sql + Migrationen + deployDump = aktuelle Datenbankstruktur. Eine solche Datei kann mit dem Tool pg_dumpgeneriert werden. Es wird base.sql ausschließlich beim Initialisieren einer Datenbank von Grund auf verwendet.

Wir nennen das Skript zur vollständigen Initialisierung der Datenbank refresh.sh. Der Arbeitsprozess könnte folgendermaßen aussehen:

1. Der Entwickler startet in seiner Umgebung refresh.sh und erhält die aktuelle Datenbankstruktur
2. Der Entwickler beginnt mit der Arbeit an der zugewiesenen Aufgabe und passt die lokale Datenbank an die Bedürfnisse der neuen Funktionalität an (ALTER TABLE ... ADD COLUMN usw.)
3. Nach Abschluss der Aufgabe ruft der Entwickler die Funktion saveDumpauf, um die in der Datenbank vorgenommenen Änderungen im VCS zu erfassen.
4. Der Entwickler startet erneut refresh.sh, dann verifyDump, die jetzt eine Liste der Änderungen für die Migration anzeigt
5. Der Entwickler überträgt alle Strukturänderungen in die Migrationsdatei und startet den Prozess erneut refresh.sh und verifyDump, und falls die Migration korrekt erstellt wurde, verifyDump wird es keine Unterschiede zwischen der lokalen DB und dem gespeicherten Dump zeigen

Der oben beschriebene Prozess ist mit den Prinzipien von Gitflow kompatibel. Jeder Branch im VCS enthält seine eigene Version des Dumps, und beim Zusammenführen der Branches wird auch das Zusammenführen der Dumps durchgeführt. In den meisten Fällen sind nach dem Mergen keine weiteren Schritte erforderlich, aber wenn in verschiedenen Branches Änderungen vorgenommen wurden, zum Beispiel an derselben Tabelle, kann es zu Konflikten kommen.

Betrachten wir eine Konfliktsituation am Beispiel: Es gibt einen Branch develop, von dem zwei Branches abgezweigt wurden: feature1 und feature2, die keine Konflikte mit develophaben, aber Konflikte untereinander aufweisen. Die Aufgabe besteht darin, beide Branches in developzu mergen. Für diesen Fall wird empfohlen, zunächst einen der Branches in developzu mergen und anschließend develop in den verbleibenden Branch, wobei die Konflikte im verbleibenden Branch gelöst werden, bevor der letzte Branch in develop. In der Phase der Konfliktlösung kann es notwendig sein, die Migrationsdatei im letzten Branch anzupassen, damit sie mit dem endgültigen Dump übereinstimmt, der die Ergebnisse der Zusammenführungen enthält.

Wie können mehrere Änderungen in der Datenbankstruktur sicher in die Produktionsumgebung deployed werden?

Dank des Dumps der aktuellen Datenbankstruktur im VCS besteht die Möglichkeit, die Produktionsdatenbank auf die genaue Übereinstimmung mit der geforderten Struktur zu überprüfen. Dies garantiert, dass alle Änderungen, die die Entwickler geplant hatten, erfolgreich in die Produktionsdatenbank übertragen wurden.

Da DDL in PostgreSQL ist transaktional, es wird empfohlen, sich an die folgende Reihenfolge des Deployments zu halten, um im Falle eines unerwarteten Fehlers die Änderungen "schmerzfrei" durchzuführen. ROLLBACK:

1. Eine Transaktion starten
2. In der Transaktion alle Migrationen durchführen
3. In derselben Transaktion durchführen deployDump
4. Ohne die Transaktion abzuschließen, durchführen verifyDump. Wenn keine Fehler vorliegen, durchführen BESTÄTIGEN. Wenn Fehler vorliegen, durchführen ROLLBACK

Diese Schritte lassen sich relativ einfach in bestehende Deploy-Ansätze integrieren, einschließlich Zero-Downtime.

Fazit

Dank der oben beschriebenen Methoden lässt sich die maximale Leistung aus Projekten mit „PHP + PostgreSQL“ herausholen, wobei relativ wenig an Entwicklungskomfort geopfert werden muss im Vergleich zur Implementierung der gesamten Geschäftslogik im Hauptcode der Anwendung. Darüber hinaus erscheint die Datenverarbeitung oft transparenter und erfordert weniger Code als dieselbe Funktionalität, die in PHP geschrieben ist. PL/pgSQL Die Zielsetzung dieses Artikels ist es, am Beispiel der Bibliothek schema-keeper die Werkzeuge vorzustellen, die den Entwicklungsprozess von Datenbanken in PHP-Projekten mit PostgreSQL erheblich vereinfachen. Die Informationen in diesem Artikel sind vor allem für Entwickler nützlich, die die Möglichkeiten von PostgreSQL optimal nutzen möchten, aber mit den Herausforderungen umgehen müssen, die mit der Auslagerung der Geschäftslogik in die Datenbank verbunden sind. Der Artikel wird nicht die Vorteile beschreiben.

Quelle: habr.com