Ziel dieses Artikels ist es, am Beispiel der Bibliothek schema-keeper Werkzeuge zu zeigen, die den Entwicklungsprozess von Datenbanken in PHP-Projekten mit PostgreSQL-Datenbanken erheblich erleichtern.

Die Informationen aus diesem Artikel werden vor allem für Entwickler nützlich sein, die die Möglichkeiten von PostgreSQL maximieren möchten, aber auf Probleme bei der Pflege der in die Datenbank ausgelagerten Geschäftlogik stoßen.

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

Es werden folgende Fragen behandelt:

1. In welcher Form soll der Dump der Datenbankstruktur im Versionskontrollsystem (nachfolgend VCS) gespeichert werden?
2. Wie können Änderungen an der Datenbankstruktur nach der Speicherung des Dumps verfolgt werden?
3. Wie können Änderungen an der Datenbankstruktur ohne Konflikte und riesige Migrationsdateien auf andere Umgebungen übertragen werden?
4. Wie kann der Prozess der parallelen Arbeit mehrerer Entwickler am Projekt organisiert werden?
5. Wie können mehrere Änderungen an der Datenbankstruktur sicher in die Produktionsumgebung deployed werden?
   

   SchemaKeeper ist auf die Arbeit mit gespeicherten Prozeduren ausgelegt, die in der Sprache PL/pgSQLgeschrieben sind. Tests mit anderen Sprachen wurden nicht durchgeführt, daher könnte die Nutzung weniger effektiv oder unmöglich sein.

In welcher Form soll der Dump der Datenbankstruktur im VCS gespeichert werden?

Bibliothek schema-keeper stellt die Funktion saveDumpbereit, die die Struktur aller Objekte aus der Datenbank in Form von separaten Textdateien speichert. Als Ergebnis wird ein Verzeichnis erstellt, das die Struktur der Datenbank enthält, aufgeteilt in gruppierte Dateien, die leicht ins VCS hinzugefügt werden können.

Betrachten wir die Umwandlung von Objekten aus der Datenbank in Dateien an mehreren Beispielen:

Objekttyp
Diagramm
Bezeichnung
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 der Datei für gespeicherte Prozeduren die vollständige Definition der gespeicherten Prozedur enthalten, die mit dem Block beginnt CREATE OR REPLACE FUNCTION.

Wie aus der obigen Tabelle ersichtlich, enthält der Pfad zur Datei Informationen über den Typ, das Schema und den Namen des Objekts. Dieser Ansatz erleichtert die Navigation durch den Dump und das Code-Review von Änderungen in der Datenbank.

Erweiterung .sql Für Dateien mit Quellcode von gespeicherten Prozeduren wurde gewählt, damit die IDE beim Öffnen der Datei automatisch Tools zur Interaktion mit der Datenbank bereitstellt.

Wie können Änderungen an der Datenbankstruktur nach der Speicherung des Dumps verfolgt werden?

Durch das Speichern eines Dumps der aktuellen Datenbankstruktur in VCS 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 Datenbankstruktur. verifyDump, die ohne Nebenwirkungen Informationen über die Unterschiede zurückgibt.

Ein alternativer Prüfweg besteht darin, die Funktion noch einmal aufzurufen saveDump, wobei das gleiche Verzeichnis angegeben wird, und die Änderungen im VCS zu überprüfen. Da alle Objekte der Datenbank in separaten Dateien gespeichert sind, wird VCS nur die geänderten Objekte anzeigen.
Der Hauptnachteil dieser Methode ist die Notwendigkeit, die Dateien zu überschreiben, um die Änderungen zu sehen.

Wie können Änderungen an der Datenbankstruktur ohne Konflikte und riesige Migrationsdateien auf andere Umgebungen übertragen werden?

wissen wir dank der Funktion deployDump Der Quellcode von gespeicherten Prozeduren kann ganz ähnlich wie der reguläre Quellcode einer Anwendung bearbeitet werden. Man kann neue Zeilen im Code der gespeicherten Prozeduren hinzufügen/entfernen und sofort die Änderungen in das Versionskontrollsystem übermitteln oder gespeicherte Prozeduren erstellen/löschen, indem man entsprechende Dateien im Dump-Verzeichnis erstellt/löscht.

Zum Beispiel reicht es aus, um eine neue gespeicherte Prozedur im Schema public zu erstellen, eine neue Datei mit der Erweiterung .sql wird im Verzeichnis public/functions, zu erstellen, den Quellcode der gespeicherten Prozedur inklusive des Blocks CREATE OR REPLACE FUNCTION, dort einzufügen und dann die Funktion deployDumpaufzurufen. Auf die gleiche Weise erfolgt die Änderung und Löschung einer gespeicherten Prozedur. Auf diese Weise gelangt der Code gleichzeitig in VCS und in die Datenbank.

Wenn im Quellcode einer gespeicherten Prozedur ein Fehler auftritt oder eine Diskrepanz zwischen dem Dateinamen und der gespeicherten Prozedur besteht, wird deployDump nicht ausgeführt und gibt den Fehlertext aus. Eine Diskrepanz zwischen den gespeicherten Prozeduren im Dump und der aktuellen Datenbank ist mit Hilfe von deployDump.

bei der Erstellung einer neuen gespeicherten Prozedur nicht erforderlich, den richtigen Dateinamen manuell einzugeben. Es reicht aus, dass die Datei die Erweiterung .sqlhat. Nach dem Aufruf wird deployDump der Fehlertext den richtigen Namen enthalten, der verwendet werden kann, um die Datei umzubenennen.

deployDump erlaubt es, die Parameter der Funktion oder den Rückgabetyp ohne zusätzliche Maßnahmen zu ändern, während man beim klassischen Ansatz zuerst
DROP FUNCTION ausführen müsste, und erst danach, und dann erst CREATE OR REPLACE FUNCTION.

Leider gibt es einige Situationen, in denen deployDump die Änderungen nicht automatisch übernommen 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 durch die schema-keeperverantwortlich ist, müssen für den Transfer der anderen Änderungen in der Struktur Migrationsdateien verwendet werden. Eine gute Bibliothek für die Arbeit mit Migrationen ist doctrine/migrations.

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

Eine detailliertere Arbeit mit Migrationen wird in den folgenden Abschnitten beschrieben.

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

Es ist notwendig, ein Skript zur vollständigen Initialisierung der Datenbank zu erstellen, das von den Entwicklern auf ihren Arbeitsmaschinen ausgeführt wird, um die Struktur der lokalen Datenbank mit dem in VCS gespeicherten Dump abzugleichen. Am einfachsten ist es, die Initialisierung der lokalen Datenbank in 3 Schritte zu teilen:

1. Importieren der Datei mit der Basisstruktur, die beispielsweise genannt wird base.sql
2. Anwendung der Migrationen
3. Aufruf deployDump

base.sql — dies ist der Ausgangspunkt, über dem Migrationen angewendet werden, und es wird deployDump, das heißt base.sql + Migrationen + deployDump = aktuelle Struktur der Datenbank. Eine solche Datei kann mit dem Dienstprogramm erstellt werden pg_dump. Wird base.sql ausschließlich bei der Initialisierung einer Datenbank von Grund auf verwendet.

Nennen wir 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 Struktur der Datenbank
2. Der Entwickler beginnt mit der Arbeit an der gestellten Aufgabe, indem er die lokale Datenbank an die Bedürfnisse der neuen Funktionalität anpasst (ALTER TABLE ... ADD COLUMN usw.)
3. Nach der Durchführung der Aufgabe ruft der Entwickler die Funktion saveDumpauf, um die in der Datenbank vorgenommenen Änderungen in VCS zu dokumentieren
4. Der Entwickler startet erneut refresh.sh, dann verifyDump, was jetzt eine Liste der Änderungen zeigt, die in die Migration aufgenommen werden sollen
5. Der Entwickler überträgt alle Strukturänderungen in die Migrationsdatei, startet ein weiteres Mal refresh.sh und verifyDump, und wenn die Migration korrekt erstellt wurde, verifyDump zeigt es keine Unterschiede zwischen der lokalen Datenbank und dem gespeicherten Dump an.

Der oben beschriebene Prozess ist mit den Prinzipien von Gitflow kompatibel. Jeder Branch im VCS wird seine eigene Version des Dumps enthalten, und beim Zusammenführen der Branches wird die Zusammenführung der Dumps durchgeführt. In den meisten Fällen sind nach dem Zusammenführen keine weiteren Schritte erforderlich, aber wenn in verschiedenen Branches Änderungen vorgenommen wurden, beispielsweise an derselben Tabelle, kann ein Konflikt auftreten.

Betrachten wir eine Konfliktsituation am Beispiel: Es gibt einen Branch develop, von dem zwei Branches abgezweigt werden: feature1 und feature2, die keine Konflikte mit develophaben, aber Konflikte miteinander. Es steht die Aufgabe an, beide Branches in developzusammenzuführen. In einem solchen Fall wird empfohlen, zunächst einen der Branches in developzusammenzuführen und dann die develop in den verbleibenden Branch zu mergen, dabei die Konflikte im verbleibenden Branch zu lösen, bevor man den letzten Branch in developzusammenführt. In der Phase der Konfliktlösung könnte es notwendig sein, die Migrationsdatei im letzten Branch zu korrigieren, damit sie dem endgültigen Dump entspricht, der die Ergebnisse der Zusammenführungen umfasst.

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

Durch die Verfügbarkeit eines aktuellen Dumps der DB-Struktur im VCS wird es möglich, die Produktionsdatenbank auf die genaue Übereinstimmung mit der erforderlichen Struktur zu überprüfen. Dies garantiert, dass alle Änderungen, die die Entwickler vorgesehen hatten, erfolgreich in die Produktionsdatenbank übertragen wurden.

Da das DDL in PostgreSQL ist transaktional, es wird empfohlen, die folgende Reihenfolge beim Deployment einzuhalten, um im Falle eines unerwarteten Fehlers das Ganze "schmerzlos" auszuführen: ROLLBACK:

1. Transaktion starten
2. Alle Migrationen in der Transaktion ausführen
3. In derselben Transaktion deployDump
4. ausführen verifyDump. Ohne die Transaktion zu beenden, durchführen COMMIT. Wenn keine Fehler auftreten, die ROLLBACK

. Wenn Fehler auftreten, führen Sie

Fazit

Diese Schritte lassen sich recht leicht in bestehende Deployment-Ansätze integrieren, einschließlich zero-downtime. PL/pgSQL Dank der oben beschriebenen Methoden kann man das Maximum an Leistung aus "PHP + PostgreSQL"-Projekten herausholen, und dabei wird im Vergleich zur Implementierung der gesamten Geschäftslogik im Hauptcode des Projekts relativ wenig an Entwicklungskomfort geopfert. Darüber hinaus erscheint die Datenverarbeitung in

Quelle: habr.com