Danke für den Vorschlag. Ich kann momentan nicht überblicken ob der nur mit PostgreSQL umsetzbar (möglicherweise auch nur im Sinne "vorteilhaft" umsetzbar) ist.
Ich fürchte das die Entscheidung für MySQL gefallen ist.
Gut, also die Entscheidung ist gefallen. Noch besser, Entscheidungen können auch revidiert werden. Man merkt ja an Deiner Fragestellung, dass Du mit Anspruch an die Sache gehst und Dir Gedanken machst. Das „nur mit Postgres“ an einer anderen Stelle Deines Beitrags kannst Du sicher streichen, aber das „vorteilhaft“ ist der spannende Punkt.
Mal ein kleiner Zukunftsentwurf: Was glaubst Du, wie diese Entscheidung „skaliert“? (um mal ein gern benutztes IT Wort etwas anders zu verwenden) Nicht wegen Performance oder Datenvolumen-was man auch gerne betrachten kann-, Du sitzt da jetzt an einem einzigen Problem. Wie viel Tage wirst Du noch daran sitzen? Der Vorschlag, Dir die MySQL Threads mal etwas durchzulesen, kam ja schon. Meine Prognose ist, es gibt dutzende, eher hunderte solcher Probleme bei einem mittelgroßen Projekt. Dass Du ganz am Anfang stehst und nicht gut abschätzen kannst, was da auf Dich zu kommt und was ein besserer Lösungsansatz sein kann, macht die Sache nicht leichter.
Nächste Frage: Wie weit bist Du mit dem Projekt, sagen wir mal, wie viel Tabellen, Trigger, Views, Stored Procedures? 50 Tabellen, 100 .. ?
Stell Dir vor, es kostet Dich 3 Tage, das Datenmodel auf Postgres anzupassen. Stell Dir außerdem vor, dass Du dabei oder folgend, wenn Du Postgres besser kennst, noch ein paar hässliche Ecken beseitigen kannst (auch im Client Code! Dort werden ja die meisten Probleme ausgebügelt), weil Du eine Handvoll sogenannter „Workarounds“ einfach entsorgen kannst. Nehmen wir noch 1 Tag für die Postgres Installation. Auch hier gibt es vielleicht Lernbedarf, das einfachste unter Linux, eine Zeile, dann ist es installiert und lokal nutzbar:
sudo apt -y install postgresql
Es gibt „aufwändigere“ Varianten, je nach Bedarf, 2 Configdateien, 2 Zeilen ändern, dann hat man Netzwerkzugriff bzw. Authentisierungsverfahren. Direkt das Postgres Repository einbinden, dann hat man unabhängig von der Distribution das neueste Postgres. Nehmen wir noch ein paar Tage für die Installation anderer Tools, umgewöhnen. Okay, der Umstellungsaufwand ist vollkommen geraten und hängt nicht nur von dem Istzustand ab, auch von der allgemeinen Erfahrung mit DB Entwicklung. Hast Du schon viel Programm Code in der DB?
Würde es einem MySQL Admin Probleme bereiten? Nun, ich kann es nicht sagen. Aber vielleicht will man sich weiter entwickeln, statt sich bloß Problem getrieben durch ein Projekt zu quälen. Ich arbeite seit > 10 Jahren nebenher mit Postgres. Es sind keine großen Projekte (DB) und es gibt wenig Last, keine wirklichen Herausforderungen für Postgres, das älteste läuft seit 8 Jahren produktiv in einer VM, eine wirklich kleine Installation. Keine nennenswerten, administrativen Maßnahmen. Von allen Problemen im Projekt war kein einziges ein Postgres Problem. Zum Vergleich, vor ca. einem Jahr haben wir ein Oracle System abgestellt, >10 Mio. Buchungsdatensätze, ein recht komplexes Datenmodell, dutzende Packages, entsprechend mehr Prozeduren und Funktionen (also ein System, das als wesentlichen Bestandteil auch Programmcode nutzt). Das würde ich heute mit Postgres machen, auch ohne Programmierung, niemals mit MySQL, eher würde ich kündigen.
Nun, man macht nicht mal eben eine Migration eines laufenden Projekts. Wenn man noch am Anfang ist, kann sich so was rechnen schnell rechnen, nicht nur in Euro, auch in Synapsen.
...)
