Mein Problem dabei ist, wenn auch nur ein Script dazwischen fehlt, das das schnell in die Hose. Und auch die Scripte muss ich ja irgendwie liefern oder im Programm hinterlegen.
Ja, die musst du mitliefern uns nein, natürlich darf da Keines fehlen. Aber: In den Update-Skripten (Migrationen) kannst du gleichzeitig auch die Daten migrieren!
Zitat:
Deswegen möchte ich ja einen Soll-Stand mit einem Ist-Stand vergleichen um dann gezielt nur die Änderungen auszuführen.
Was ich geschrieben habe mit dem Ändern von Tabellennamen oder Feld-Definitionen, das kommt eher seltener vor (Kann aber, und daher will ich das gleich vorsehen).
Hier klappt das dann nicht so gut, weil du von allen x Vorgängerversionen in der Lage sein müsstest, die Daten zu migrieren. Wenn du das richtig machen willst, wird der Aufwand immer größer!
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
