Habe mal ein Projekt mit Entity Framework 6 und Migrationen gemacht, da hat das super funktioniert. Falls man eine Relation von 1:1 zu 1:n gewachsen ist: Neue Tabelle anlegen,
SQL Befehl um die Daten zu kopieren und alte Tabelle anpassen. Ist eine Migration und man kann auch eine Rückmigration machen, wenn man die Funktion auch befüllt
Hab mir mal ein Video dazu angesehen. Sicherlich ein tolles Tool. Aber für meine Zwecke doch zu Aufwendig. Ich ja von MS, kann das auch mit
MySQL oder Firebird umgehen?
Evtl. wäre ein ORM Mapper was für dich? Damit könntest du die Strukturen via Objektattribute bestimmen. Das System kann dann die Struktur deiner Objekte auf die
DB mappen und ggf. die Datenbankstruktur anpassen.
https://www.tmssoftware.com/site/aurelius.asp
https://bitbucket.org/soundvibe/marshmallow/wiki/Home
und natürlich einige weitere, aber das sind die, die ich bisher getestet habe.
Aurelius läst sich meiner Meinung nach besser an bestehende Datenbanken anpassen. Die Zugriffe funktionieren performant. Sping4D ist OpenSource, hat aber nicht so viele Möglichkeiten wie Aurelius. Aber es wird stetig an beiden ORMs weitergearbeitet (mein Eindruck) und immer wieder verbessert.
Danke für die Links. Aurelius kannte ich schon, das andere nicht. Ich werde mir das mal genauer anschauen. Allerdings bin ich gerade eher "weg von Third-Party" eingestellt
Deswegen möchte ich ja einen Soll-Stand mit einem Ist-Stand vergleichen um dann gezielt nur die Änderungen auszuführen.
Ich finde den Abschnitt sehr wesentlich.
Man braucht eine definierte Zielvorgabe. Das wäre die einzig sinnvolle Grundlage für alle Änderungsvorgänge. Für die Vorgabe kann man verschiedene Möglichkeiten nutzen, z.B. ein leeres DM Script, ggF. mit teilweise gefüllten Konfigurationsdaten (Default Customization)
Dann kann es diese Zielvorgabe auch in abstrakter Form geben, also bspw. eine Versionstabelle, die modulweise die vorhandenen Versionen anzeigt plus mögliche Upgrades/Upgrade Pfade mit statischen Scripten je Version.
Nebenbei: Kannst Du sicherstellen, dass ein Istzustand nicht vom Nutzer verfremdet wurde?
Migration:
Hier wird ja klassisch am lebenden Objekt gearbeitet. (Oder gern auf einer Staging Kopie, ..)
Als Alternative kann man auch überlegen, ein komplett neues System hochzuziehen. Das bietet sich vielleicht bei starker Restrukturierung an. Programmupdates, Neuerungen sind ja oft einfach Erweiterungen, gern abwärtskompatibel. Deine Beschreibung der Änderungen klingt aber etwas radikaler, daher ist es vielleicht hilfreich, nicht das Altsystem zu verändern, sondern neu aufsetzen und Altdaten rüberziehen. Das kann man notfalls solange machen, bis es funktioniert- ohne das Altsystem abzuschießen, es wäre damit jederzeit verfügbar, falls eine Migration fehlschlägt.
Diese Variante hätte den Vorteil, dass das alte System weiterlaufen könnte / ausgeschlichen werden kann, wenn nötig. Notfalls könnte sogar live auf alt und neu gearbeitet werden. Das neue System hätte dann Views ins alte System. Aber das macht man natürlich nicht ohne Not.
Ein ganz neues System aufzusetzen hat neben diversen Vorteilen allerdings den Nachteil, dass mindestens für den Migrationszeitraum / Parallelbetrieb die
DB Ressourcen doppelt vorhanden sein müssen. (Was sie allerdings häufig sowieso sind in Form von Hot Standby usw. Systemen)
Was ist es überhaupt für ein System? Lokale Anwendung (ala Musikdatenbank , .. ) oder eher eine Firmensoftware?
Die Zielvorgabe ist immer der Stand der neuesten Programmversion.
Die grundsätzlich
DB-Struktur steht fest und wird sich auch nicht wesentlich verändern. Mit dieser Struktur läuft das Programm seit mehr als 12 Jahren.
Es ist noch unter D7 geschrieben und beinhaltet einige Fremdkomponenten. Das, und die Tatsache, dass es über die Jahre an vielen Ecken "angestückelt" wurde, macht eine direkte Übernahme sehr Aufwendig. Auch sollen alle Fremdkomponenten durch eigene Komponenten ersetzt werden. Einzig ein paar
Jedi-Komponenten, und die
DB-Komponente sollen weiterhin Third-Party bleiben. Deswegen habe ich mich entschlossen, es von Grund auf neu zu schreiben. Die
DB-Struktur soll aber im wesentlichen erhalten bleiben.
Für die Neuentwicklung könnte ich die
DB auch von Hand anlegen und jeweils erweitern. Und vor Auslieferung wird auch ein ausgiebiger Migrationstest stattfinden, so dass alle Daten aus der bisherigen Struktur übernommen werden können.
Allerdings wird es auch nach Fertigstellung eine Weiterentwicklung geben. Und da geht es letztlich oft nur um Kleinigkeiten z.B: ein Datenfeld ist zu klein, ein Datentyp wird geändert, weil er sich so besser verarbeiten lässt, usw. Und natürlich wenn gänzlich neue Funktionen hinzukommen auch mal ein neue Tabelle.
Das soll aber so geschehen, wie es auch bisher ist, dass der Kunde eben die neue Version herunterladen kann, und beim ersten Start die
DB im Programm angepasst wird (solche Dinge wie Update nur wenn keine anderen Clients laufen, und Programmstart verhindern wenn
DB-Update läuft, sind bereits berücksichtigt). So war es auch die letzt 12 Jahre und so sollte es auch im neuen Programm laufen.
Das ein Kunde die
DB-Struktur verändert kann ich nahezu ausschließen. Zwar nicht in letzter Konsequenz, aber wer mutwillig rumspielt und manipuliert hat halt Pech. Dafür gibt's ja Datensicherungen.
Ich möchte nun den Aufwand für mich relativ gering halten und auch dafür sorgen, dass alle Vorgänge nahezu automatisch ablaufen. Aber es sind mittlerweile ca 70 Tabellen. Also kommt schon etwas zusammen.
Ich muss mir das alles noch ein wenig durch den Kopf gehen lassen.