Ich bin in der Forschungsphase und versuche, 2012-Datenbankprojekte für ein vorhandenes kleines Projekt zu übernehmen. Ich bin ein C # -Entwickler und kein DBA. Daher kann ich mit Best Practices nicht besonders gut umgehen. Ich habe jetzt einige Stunden lang nach Google und Stackoverflow gesucht, weiß aber immer noch nicht, wie ich mit einigen wichtigen Bereitstellungsszenarien richtig umgehen soll.

1) Wie verwalte ich im Verlauf mehrerer Entwicklungszyklen mehrere Versionen meiner Datenbank? Wie verwalte ich einen Client in Version 3 meiner Datenbank, der auf Version 8 aktualisiert werden soll? Derzeit verwalten wir handgefertigte Schema- und Datenmigrationsskripts für jede Version unseres Produkts. Müssen wir dies noch separat tun oder gibt es etwas in dem neuen Paradigma, das dies unterstützt oder ersetzt?

2) Wenn sich das Schema so ändert, dass Daten verschoben werden müssen, wie kann dies am besten gehandhabt werden? Ich gehe davon aus, dass das Pre-Deployment-Skript einige Arbeiten ausführt, um die Daten zu erhalten, und dass das Post-Deploy-Skript sie dann wieder an die richtige Stelle zurücksetzt. Ist das so oder gibt es etwas Besseres?

3) Jeder andere Rat oder jede Anleitung, wie man am besten mit diesen neuen Technologien umgeht, wird ebenfalls sehr geschätzt!

AKTUALISIEREN: Seit ich diese Frage ursprünglich gestellt habe, ist mein Verständnis für das Problem ein wenig gewachsen, und obwohl ich eine praktikable Lösung gefunden habe, war es nicht ganz die Lösung, auf die ich gehofft hatte. Hier ist eine Umformulierung meines Problems:

Das Problem, das ich habe, ist rein datenbezogen. Wenn ich einen Client in Version 1 meiner Anwendung habe und ihn auf Version 5 meiner Anwendung aktualisieren möchte, hätte ich keine Probleme, wenn die Datenbank keine Daten enthält. Ich würde SSDT einfach auf intelligente Weise Schemata vergleichen lassen und die Datenbank auf einmal migrieren. Leider haben Kunden Daten, so einfach ist das nicht. Das Schema ändert sich von Version 1 meiner Anwendung zu Version 2 zu Version 3 (usw.). Alle Auswirkungsdaten. Meine derzeitige Strategie zur Datenverwaltung erfordert, dass ich für jedes Versions-Upgrade ein Skript verwalte (1 auf 2, 2 auf 3 usw.). Dies hindert mich daran, direkt von Version 1 meiner Anwendung zu Version 5 zu wechseln, da ich kein Datenmigrationsskript habe, um direkt dorthin zu gelangen. Die Aussicht, benutzerdefinierte Upgrade-Skripte für jeden Client zu erstellen oder Upgrade-Skripte zu verwalten, um von jeder Version zu jeder höheren Version zu wechseln, ist exponentiell unüberschaubar. Ich hatte gehofft, dass es eine Art Strategie gibt, mit der SSDT die Verwaltung der Datenseite der Dinge vereinfacht, vielleicht sogar so einfach wie die Schemaseite der Dinge. Meine jüngsten Erfahrungen mit SSDT haben mir keine Hoffnung auf eine solche Strategie gegeben, aber ich würde es gerne anders herausfinden.