MySQL und PostgreSQL als native Backend-Varianten

Die Wahl der Datenbank ist Teil der Bereitstellungsarchitektur

Bei einem Unternehmenssystem wird die Datenbank nicht nur durch die Vorliebe eines Entwicklers bestimmt. Ein Unternehmen kann eigene Betriebsstandards, ein bestehendes Datenbankteam, eingeführte Sicherungsverfahren, Anforderungen des Cloud-Anbieters oder Grenzen des verwalteten Hostings haben. Sapphire I.C.D.S. unterstützt deshalb zwei native Backend-Varianten, MySQL und PostgreSQL, und zwingt nicht jede Installation zur Nutzung einer vorab ausgewählten Datenbank.

Die öffentliche Roadmap dokumentiert die PostgreSQL-Unterstützung als veröffentlichte Verbesserung zusammen mit der vollständigen Auswahl zwischen beiden Systemen. Auf Architekturebene bedeutet das mehr als das Vorhandensein eines zweiten Treibers: Abfragen, Modulschemas und Ausführungsregeln müssen für beide Dialekte vorhanden sein und ein vergleichbares Verhalten bewahren.

Ein gemeinsamer Vertrag für zwei Treiber

Die höheren Ebenen von Sapphire I.C.D.S. sollen nicht direkt von der Clientbibliothek einer bestimmten Datenbank abhängen. Der Datencontroller liest den gewählten Backend-Typ aus der Konfiguration und erhält den entsprechenden nativen Treiber. Für das aufrufende Modul bleibt ein gemeinsamer Satz von Operationen bestehen: Zeilen lesen, Daten ändern, Einzelwerte abrufen, Stapel einfügen, Transaktionen steuern und Schemaoperationen ausführen.

Diese Trennung hält die Technologieentscheidung in der Infrastrukturschicht. Ein Artikel- oder Lokalisierungsmodul formuliert eine fachliche Anfrage und arbeitet mit einem strukturierten Ergebnis, statt über die Verbindung zu MySQL oder PostgreSQL zu entscheiden. Gleichzeitig werden Datenbankunterschiede nicht durch vermeintliche Magie verdeckt; der passende Treiber und SQL-Dialekt behandeln sie.

Getrennte SQL-Vorlagen statt bedingter Zeichenketten

Sapphire I.C.D.S. hält gewöhnliche Abfragen außerhalb des Modulcodes und trennt sie nach Dialekt. Für eine Geschäftsoperation können MySQL- und PostgreSQL-Vorlagen mit demselben Zweck und derselben erwarteten Ergebnisform existieren. Vor der Ausführung wählt der aktive Treiber die richtige Variante, wendet die native Parameterschicht an und liefert Daten in einem gemeinsamen tabellarischen Träger zurück.

Das ist eine ehrlichere Portabilität als die Behauptung, jedes SQL sei universell. MySQL und PostgreSQL unterscheiden sich bei Syntax, Typen, Kennungen, Rückgabe erzeugter Werte und Details einzelner Ausdrücke. Getrennte prüfbare Vorlagen machen diese Unterschiede sichtbar, ohne das Geschäftsmodul mit bedingten Verzweigungen zu füllen.

Was für Module gleich bleibt

• Die Fachoperation. Eine Liste, das Speichern eines Datensatzes oder eine transaktionale Änderung hat einen einheitlichen Geschäftszweck.
• Eingabedaten. Das Modul übergibt strukturierte Parameter über den gemeinsamen Bereich.
• Ergebnisform. Der Verbraucher erhält eine Tabelle oder einen Wert mit vereinbarten Feldern.
• Transaktionsgrenze. Operationen, die vollständig abgeschlossen werden müssen, verwenden den gemeinsamen Transaktionsvertrag.
• Backend-Auswahl. Konfiguration und Controller führen sie aus, nicht im Modul verteilte Bedingungen.

Was die Backend-Auswahl nicht automatisch leistet

Zwei native Varianten bedeuten nicht, dass eine laufende Produktionsdatenbank über eine einzelne Einstellung gewechselt werden kann. Eine Migration zwischen Datenbanksystemen erfordert die Übertragung von Schema und Daten, Prüfung von Sequenzen und Kennungen, Vergleich von Typen sowie Kontrolle von Kodierungen, Indizes und Transaktionsverhalten. Benötigt werden Sicherung, Stillstands- oder Synchronisationsplan, Testlauf und Rückrollkriterien.

Die Plattform behauptet auch keine automatische Replikation zwischen MySQL und PostgreSQL, keinen eingebauten datenbankübergreifenden Ausfallschutz und keinen gemeinsamen Cluster aus zwei verschiedenen Datenbankprodukten. Diese Aufgaben gehören zur Infrastruktur und müssen getrennt geplant werden. Native Backend-Auswahl bedeutet, dass Sapphire I.C.D.S. in einer unterstützten Bereitstellung mit jeder Variante arbeiten kann, nicht dass beide jederzeit ohne Vorbereitung austauschbar sind.

Auswahl zwischen MySQL und PostgreSQL

Eine vernünftige Wahl beginnt mit der Umgebung des Kunden. Betreibt eine Organisation bereits MySQL, hat standardisierte Sicherungsverfahren und ein kompetentes Team, kann der Wechsel der Datenbank nur für ein neues Projekt ohne Nutzen bleiben. PostgreSQL ist ebenso naheliegend, wenn es Unternehmensstandard ist, in verwalteter Infrastruktur verfügbar ist und in Überwachung sowie Wiederherstellung passt.

Verglichen werden sollte nicht nur die Geschwindigkeit einer Abfrage, sondern der gesamte Lebenszyklus: verfügbare Fachkräfte, Aktualisierungen, Dienstkosten, Beobachtbarkeit, Erweiterungsrichtlinien, Wiederherstellungsverfahren und Datenanforderungen. Besondere Abfragen eines Moduls müssen mit repräsentativen Mengen gemessen werden. Der gemeinsame Vertrag beseitigt Unterschiede zwischen Optimierern und Indizes nicht.

Parität erfordert Entwicklungsdisziplin

Jede Änderung an Schema oder Abfrage muss in beiden Dialekten erscheinen, wenn ein Modul die Unterstützung beider Backends erklärt. Es genügt nicht, nur die Existenz der Dateien zu prüfen. Die Kontrolle umfasst eine saubere Installation, wiederholte Anwendung sicherer Migrationen, Lese- und Schreibtests sowie einen Ergebnisvergleich. Besondere Sorgfalt ist nötig, wenn eine Datenbank geänderte Zeilen anders meldet oder den Eingabeträger nach einer leeren Auswahl beibehält.

Diese Disziplin erhöht den Prüfaufwand, macht Portabilität aber real. Ist ein neues Modul nur für ein Backend umgesetzt, muss diese Grenze festgehalten und darf nicht hinter einer allgemeinen Aussage der Plattform versteckt werden. Die technische Leitung erhält ein klares Reifekriterium: Dieselbe Geschäftsoperation soll bei beiden unterstützten Varianten ein gleichwertiges Ergebnis liefern.

Das Ergebnis im Betrieb

Für den Eigentümer geben zwei native Backends die Freiheit, Sapphire I.C.D.S. in vorhandene Infrastruktur einzupassen und einen unnötigen Kompetenzwechsel zu vermeiden. Architekten halten Geschäftsmodule durch die gemeinsame Datenschicht von direkter Treiberbindung frei. Entwickler sehen und prüfen Unterschiede in getrennten SQL-Dialekten.

Der wesentliche Wert liegt nicht im Schlagwort der Unterstützung zweier Datenbanken, sondern in der Verantwortungsgrenze. Die Organisation wählt und betreibt das Backend, der Controller bindet den nativen Treiber an, das Modul führt die Fachoperation aus, und Tests bestätigen die Parität. Das hält die Technologieentscheidung offen, ohne die tatsächlichen Kosten von Migration und Betrieb zu verschleiern.