In meinem Büro wurde über das Erstellen eines Pakets gesprochen, das mysql-Daten (nicht Schemata / Migrationen) versionskontrolliert.
Grundsätzlich würde der Prozess so funktionieren. Denken Sie daran, dass der Client das Backend immer noch als normal verwendet und dann wie ein WordPress-Backend verwendet. Der Client würde sich anmelden, einen "Zweig" auswählen, ihm einen Namen geben, sagen wir "neue Benutzer", das würde eine komplett neue Datenbank klonen, die es dem Benutzer erlauben würde, dort "Zweig" zu arbeiten, ohne live zu wirken. Sobald der Client fertig ist, Datenänderungen vorzunehmen, würden sie dort ihren Datenzweig in den "Master" (live) zusammenführen.
Unter der Haube beim Zusammenführen würde es sowohl Live- als auch "neue Benutzer" -Verzweigungsdaten in eine SQL-Datei exportieren und einen svn-Vergleich durchführen und die Änderungen zusammenführen.
Die Situation, die die Idee hervorgerufen hat, war, wenn wir Kunden haben, die eine Menge Änderungen an der Site vornehmen müssen, aber diese Daten nicht live stellen wollen und während sie Änderungen vornehmen, wollen sie auch keine Änderungen an anderen Mitarbeitern vornehmen . Im Grunde repliziert, was Entwickler tun, wenn sie in Repositories wie Git arbeiten.
Auch wenn der Client auf einer Dev / Demosite arbeitet, wollen sie die Arbeit live stellen.
Ich wollte die Diskussion öffnen, um zu verstehen, ob das überhaupt eine gute Idee ist? Auf welche Probleme können wir stoßen? Ist das eine gute Programmierpraxis beim Arbeiten mit Daten? Gibt es so etwas schon?
Die Datenbank (insbesondere ihre Daten) werden selten in einem Versionskontrollsystem gespeichert, da sie für große Datenbanken nicht gut skalierbar ist.
In Ihrem Fall, wenn Sie nicht zu viele Daten haben, könnte das funktionieren, insbesondere seit mysqldump kann ein begrenztes text -Format erzeugen (welches eine Chance hat, sich von der vorherigen Version zu unterscheiden)
Ich würde immer noch ein separates Git Repo und ein spezielles Tool empfehlen, um sowohl Schema- als auch Datenänderungen zu verwalten. Zum Beispiel kann LiquidBase "Quellcodeverwaltung für Ihre Datenbank" bereitstellen.
Sie haben auch als dedizierte spezialisierte Datenbank: außerhalb der Skala .
Wenn Sie dies manuell tun würden, haben Sie gute Praktiken in " Rezepte für die fortlaufende Datenbankintegration " zusammengefasst.
Wie hier erwähnt , sogar für das Schema:
Ich habe auf die harte Tour gelernt, dass das Anwenden von Änderungen des Datenbankschemas ohne einen umfassenden Schritt-für-Schritt-Plan nicht zuverlässig durchgeführt werden kann, und in ähnlicher Weise ist die Reihenfolge der Beziehungsabhängigkeiten wichtig Das Speichern des "aktuellen" oder "Ende" Schemas ist nicht ausreichend. Es gibt viele Änderungen, die nicht rückwirkend angewendet werden können
A->C, ohneA->B->Czu kennen und einige ÄnderungenBkönnen eine Migrationslogik oder Korrekturen beinhalten.
Sind Ihre Anforderungen so einfach wie folgt:
Wenn dies die Anforderungen sind, können Sie mehrere Datenbanken verwenden. Betrachten Sie die folgenden Datenbanken in einem MySQL-Server:
Diese Datenbanken teilen genau dasselbe Schema und nur die Daten sind unterschiedlich. In jeder Verzweigung haben wir eine spezielle Tabelle (d. H. Dbinfo), um den übergeordneten Zweig (wahrscheinlich masterdb) zu verfolgen, datetime und andere Details, wie Zugangsebene usw. zu erstellen.
Sie können Endbenutzern erlauben, in separaten Zweigen zu arbeiten, indem Sie ihnen einfach erlauben, eine bestimmte Datenbank in der Benutzeroberfläche auszuwählen, wobei Masterdb als Standard ausgewählt ist und in LIVE verwendet wird.
Wenn Sie Änderungen an den Daten verfolgen möchten, können Sie eine spezielle Tabelle zum Protokollieren der Aktivitäten erstellen.