Der Zweck dieses Artikels besteht darin, das Beispiel einer Bibliothek zu verwenden Schema-Bewahrer zeigen Tools, die den Prozess der Datenbankentwicklung innerhalb von PHP-Projekten mithilfe des PostgreSQL-DBMS erheblich vereinfachen können.

Die Informationen aus diesem Artikel werden vor allem für Entwickler nützlich sein, die die PostgreSQL-Funktionen optimal nutzen möchten, aber Probleme bei der Verwaltung der in der Datenbank platzierten Geschäftslogik haben.

In diesem Artikel werden nicht die Vor- oder Nachteile der Speicherung von Geschäftslogik in einer Datenbank beschrieben. Es wird davon ausgegangen, dass der Leser die Wahl bereits getroffen hat.

Folgende Fragen werden berücksichtigt:

1. In welcher Form sollte ein Datenbankstruktur-Dump in einem Versionskontrollsystem (im Folgenden als VCS bezeichnet) gespeichert werden?
2. So verfolgen Sie Änderungen in der Datenbankstruktur nach dem Speichern eines Dumps
3. So übertragen Sie Änderungen in der Datenbankstruktur ohne Konflikte und riesige Migrationsdateien in andere Umgebungen
4. So organisieren Sie den Prozess der parallelen Arbeit mehrerer Entwickler an einem Projekt
5. So stellen Sie weitere Änderungen in der Datenbankstruktur sicher in einer Produktionsumgebung bereit
   

   SchemaKeeper Entwickelt für die Arbeit mit gespeicherten Prozeduren, die in der Sprache geschrieben sind PL / pgSQL. Tests mit anderen Sprachen wurden nicht durchgeführt, daher ist die Verwendung möglicherweise nicht so effektiv oder nicht möglich.

So speichern Sie einen Datenbankstruktur-Dump in VCS

Bibliothek Schema-Bewahrer stellt eine Funktion bereit saveDump, das die Struktur aller Objekte aus der Datenbank als separate Textdateien speichert. Die Ausgabe ist ein Verzeichnis mit der Datenbankstruktur, aufgeteilt in gruppierte Dateien, die einfach zu VCS hinzugefügt werden können.

Schauen wir uns anhand einiger Beispiele die Konvertierung von Objekten aus einer Datenbank in Dateien an:

Objekttyp
Fahren
Name
Relativer Pfad zur Datei

Tabelle
Öffentlichkeit
Konten
./public/tables/accounts.txt

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

Einleitung
Buchung
Tarife
./booking/views/tariffs.txt

Der Inhalt der Dateien ist eine Textdarstellung der Struktur eines bestimmten Datenbankobjekts. Bei gespeicherten Prozeduren ist der Inhalt der Datei beispielsweise die vollständige Definition der gespeicherten Prozedur, beginnend mit dem Block CREATE OR REPLACE FUNCTION.

Wie aus der obigen Tabelle ersichtlich ist, werden im Pfad zur Datei Informationen über Typ, Schema und Name des Objekts gespeichert. Dieser Ansatz erleichtert die Navigation durch den Dump und die Codeüberprüfung von Änderungen in der Datenbank.

Expansion .sql Für Dateien mit gespeichertem Prozedurquellcode wurde dies ausgewählt, damit die IDE beim Öffnen der Datei automatisch Tools für die Interaktion mit der Datenbank bereitstellt.

So verfolgen Sie Änderungen in der Datenbankstruktur nach dem Speichern eines Dumps

Durch das Speichern eines Dumps der aktuellen Datenbankstruktur in VCS erhalten wir die Möglichkeit zu überprüfen, ob nach der Erstellung des Dumps Änderungen an der Datenbankstruktur vorgenommen wurden. In der Bibliothek Schema-Bewahrer Um Änderungen in der Datenbankstruktur zu erkennen, wird eine Funktion bereitgestellt verifyDump, das Informationen über die Unterschiede ohne Nebenwirkungen zurückgibt.

Eine alternative Möglichkeit zur Überprüfung besteht darin, die Funktion erneut aufzurufen saveDump, geben Sie dasselbe Verzeichnis an und prüfen Sie im VCS auf Änderungen. Da alle Objekte aus der Datenbank in separaten Dateien gespeichert werden, zeigt VCS nur geänderte Objekte an.
Der Hauptnachteil dieser Methode besteht darin, dass Dateien überschrieben werden müssen, um die Änderungen zu sehen.

So übertragen Sie Änderungen in der Datenbankstruktur ohne Konflikte und riesige Migrationsdateien in andere Umgebungen

Dank der Funktion deployDump Der Quellcode gespeicherter Prozeduren kann auf genau die gleiche Weise bearbeitet werden wie der reguläre Quellcode einer Anwendung. Sie können neue Zeilen im Code gespeicherter Prozeduren hinzufügen/löschen und Änderungen sofort an die Versionskontrolle übertragen oder gespeicherte Prozeduren erstellen/löschen, indem Sie die entsprechenden Dateien im Dump-Verzeichnis erstellen/löschen.

Zum Beispiel, um eine neue gespeicherte Prozedur in einem Schema zu erstellen public Erstellen Sie einfach eine neue Datei mit der Erweiterung .sql im Verzeichnis public/functionsPlatzieren Sie darin den Quellcode der gespeicherten Prozedur, einschließlich des Blocks CREATE OR REPLACE FUNCTION, dann rufen Sie die Funktion auf deployDump. Das Ändern und Löschen einer gespeicherten Prozedur erfolgt auf die gleiche Weise. Somit gelangt der Code gleichzeitig in das VCS und die Datenbank.

Wenn im Quellcode einer gespeicherten Prozedur ein Fehler auftritt oder eine Diskrepanz zwischen den Namen der Datei und der gespeicherten Prozedur vorliegt, dann deployDump schlägt fehl und zeigt einen Fehlertext an. Eine Nichtübereinstimmung gespeicherter Prozeduren zwischen dem Dump und der aktuellen Datenbank ist bei Verwendung unmöglich deployDump.

Beim Erstellen einer neuen gespeicherten Prozedur ist es nicht erforderlich, den korrekten Dateinamen manuell einzugeben. Es reicht aus, wenn die Datei die Endung hat .sql. Nach dem Anruf deployDump Der Fehlertext enthält den korrekten Namen, der zum Umbenennen der Datei verwendet werden kann.

deployDump ermöglicht es Ihnen, die Parameter einer Funktion oder eines Rückgabetyps ohne zusätzliche Aktionen zu ändern, während Sie dies beim klassischen Ansatz tun müssten
zuerst ausführen DROP FUNCTION, und nur dann CREATE OR REPLACE FUNCTION.

Leider gibt es Situationen, in denen deployDump Änderungen können nicht automatisch übernommen werden. Zum Beispiel, wenn eine Triggerfunktion, die von mindestens einem Trigger verwendet wird, entfernt wird. Solche Situationen werden manuell mithilfe von Migrationsdateien gelöst.

Wenn Sie für die Migration von Änderungen an gespeicherten Prozeduren verantwortlich sind Schema-Bewahrer, dann müssen Migrationsdateien verwendet werden, um andere Änderungen in der Struktur zu übertragen. Eine gute Bibliothek für die Arbeit mit Migrationen ist beispielsweise Lehre/Migrationen.

Migrationen müssen vor dem Start angewendet werden deployDump. Auf diese Weise können Sie alle Änderungen an der Struktur durchführen und problematische Situationen beheben, sodass Änderungen in gespeicherten Prozeduren anschließend problemlos übertragen werden.

Die Arbeit mit Migrationen wird in den folgenden Abschnitten detaillierter beschrieben.

So organisieren Sie den Prozess der parallelen Arbeit mehrerer Entwickler an einem Projekt

Für die vollständige Initialisierung der Datenbank ist die Erstellung eines Skripts erforderlich, das vom Entwickler auf seinem Arbeitsrechner gestartet wird und die Struktur der lokalen Datenbank mit dem im VCS gespeicherten Dump in Einklang bringt. Am einfachsten ist es, die Initialisierung der lokalen Datenbank in 3 Schritte zu unterteilen:

1. Importieren Sie eine Datei mit einer Grundstruktur, die z. B. aufgerufen wird. base.sql
2. Anwenden von Migrationen
3. Вызов deployDump

base.sql ist der Ausgangspunkt, auf dem Migrationen angewendet und ausgeführt werden deployDumpDas heißt, base.sql + миграции + deployDump = актуальная структура БД. Sie können eine solche Datei mit dem Dienstprogramm erstellen pg_dump. Gebraucht base.sql ausschließlich beim Initialisieren der Datenbank von Grund auf.

Rufen wir das Skript zur vollständigen Datenbankinitialisierung auf refresh.sh. Der Arbeitsablauf könnte so aussehen:

1. Der Entwickler startet in seiner Umgebung refresh.sh und ruft die aktuelle Datenbankstruktur ab
2. Der Entwickler beginnt mit der Arbeit an der jeweiligen Aufgabe und ändert die lokale Datenbank, um sie an die Anforderungen der neuen Funktionalität anzupassen (ALTER TABLE ... ADD COLUMN usw)
3. Nach Abschluss der Aufgabe ruft der Entwickler die Funktion auf saveDumpum an der Datenbank in VCS vorgenommene Änderungen zu übernehmen
4. Entwickler-Relaunch refresh.shDann verifyDumpHier wird nun eine Liste der Änderungen angezeigt, die in die Migration einbezogen werden sollen
5. Der Entwickler überträgt alle Strukturänderungen in die Migrationsdatei und führt sie erneut aus refresh.sh и verifyDump, und, wenn die Migration korrekt kompiliert ist, verifyDump werden keine Unterschiede zwischen der lokalen Datenbank und dem gespeicherten Dump angezeigt

Der oben beschriebene Prozess ist mit den Gitflow-Prinzipien kompatibel. Jeder Zweig im VCS enthält seine eigene Version des Dumps, und beim Zusammenführen von Zweigen werden die Dumps zusammengeführt. In den meisten Fällen müssen nach einer Zusammenführung keine weiteren Maßnahmen ergriffen werden. Wenn jedoch Änderungen in verschiedenen Zweigen vorgenommen wurden, beispielsweise an derselben Tabelle, kann es zu einem Konflikt kommen.

Betrachten wir eine Konfliktsituation anhand eines Beispiels: Es gibt eine Filiale entwickeln, von dem zwei Zweige abzweigen: feature1 и feature2, mit denen es keine Konflikte gibt entwickeln, haben aber Konflikte untereinander. Die Aufgabe besteht darin, beide Zweige zusammenzuführen entwickeln. Für diesen Fall empfiehlt es sich, zunächst einen der Zweige zusammenzuführen entwickelnund dann zusammenführen entwickeln zum verbleibenden Zweig hinzufügen, Konflikte im verbleibenden Zweig lösen und dann den letzten Zweig zusammenführen entwickeln. Während der Konfliktlösungsphase müssen Sie möglicherweise die Migrationsdatei im letzten Zweig korrigieren, damit sie mit dem endgültigen Dump übereinstimmt, der die Ergebnisse der Zusammenführungen enthält.

So stellen Sie weitere Änderungen in der Datenbankstruktur sicher in einer Produktionsumgebung bereit

Dank des Vorhandenseins eines Dumps der aktuellen Datenbankstruktur in VCS wird es möglich, die Produktionsdatenbank auf genaue Übereinstimmung mit der erforderlichen Struktur zu überprüfen. Dadurch wird sichergestellt, dass alle von den Entwicklern beabsichtigten Änderungen erfolgreich in die Produktionsbasis übertragen wurden.

Als DDL in PostgreSQL ist transaktional, wird empfohlen, die folgende Bereitstellungsreihenfolge einzuhalten, damit Sie im Falle eines unerwarteten Fehlers „schmerzlos“ ausführen können ROLLBACK:

1. Transaktion starten
2. Führen Sie alle Migrationen in einer Transaktion durch
3. In derselben Transaktion ausführen deployDump
4. Führen Sie die Transaktion aus, ohne sie abzuschließen verifyDump. Wenn keine Fehler vorliegen, führen Sie es aus COMMIT. Wenn es Fehler gibt, führen Sie es aus ROLLBACK

Diese Schritte können problemlos in bestehende Ansätze zur Anwendungsbereitstellung integriert werden, einschließlich Null-Ausfallzeiten.

Abschluss

Dank der oben beschriebenen Methoden ist es möglich, die maximale Leistung aus „PHP + PostgreSQL“-Projekten herauszuholen und dabei im Vergleich zur Implementierung der gesamten Geschäftslogik im Hauptanwendungscode relativ wenig Entwicklungskomfort zu opfern. Darüber hinaus erfolgt die Datenverarbeitung in PL / pgSQL sieht oft transparenter aus und erfordert weniger Code als die gleiche in PHP geschriebene Funktionalität.

Source: habr.com