Nein, es ist nichts falsch mit der Verwendung einen Backup für anfängliche Bereitstellung, in der Tat würde ich sagen , dass dies oft der sicherste Weg , es zu tun. Es gibt keine "Kontamination", die auftreten kann, es sei denn, Sie haben fest codierte Dinge wie Servernamen oder Datenbanknamen, die sich in der Produktion von denen in der Testumgebung unterscheiden.
Eine Sicherung / Wiederherstellung (ähnlich wie Ihr eigenes DDL-Skript, das auf die Datenbank beschränkt ist) bringt jedoch keine Anmeldungen auf Serverebene, Verbindungsserver, SQL Agent-Jobs usw. mit sich.
Es gibt einige andere Nebeneffekte, die Sie mit einem Backup erhalten, die Sie nicht unbedingt mit einem DDL-Skript erhalten, beispielsweise wenn Sie Ihre ursprüngliche Tabelle wie folgt erstellt haben:
CREATE TABLE dbo.foo
(
bar INT PRIMARY KEY,
mort INT FOREIGN KEY REFERENCES dbo.mort(MortID),
x TINYINT CHECK (x IN (1,2)),
y INT NOT NULL DEFAULT 1
);
Alle diese Einschränkungen haben systemgenerierte Namen, wie z PK__foo__DE90ECFFA28BBAB8. Wenn Sie dasselbe Skript in der Produktion ausführen, unterscheidet sich der Name, es sei denn, Sie haben die genaue Tabellendefinition in der Testumgebung geschrieben. Dies kann später zu Problemen führen, wenn Sie aus dem Test Drop / Create / Alter-Skripte generieren und diese in der Produktion ausführen müssen.
Sie erhalten auch alle Daten in Nachschlagetabellen usw., wenn Sie eine Sicherung erstellen, die Sie manuell skripten müssen, um diese Daten in die Produktion zu bringen. (Sie müssen jedoch sicherstellen, dass Sie alle Testdaten löschen, die Sie auch in der Produktion nicht benötigen .)
Und eine Schwäche beim Herausschreiben selbst besteht darin, dass Sie sicherstellen müssen, dass alle Objekte in der richtigen Abhängigkeitsreihenfolge erstellt werden. Möglicherweise sind im Test Abhängigkeiten vorhanden, die in der Produktion fehlen, da die Objekte nicht in der richtigen Reihenfolge generiert wurden.
Wenn es darauf ankommt, ist ein Backup einfach sauberer. Und Sie sollten die Datenbank testen, wenn sie bereitgestellt wird, damit Sie alle "Kontaminationen" schnell finden und in beiden Umgebungen korrigieren können.
Sobald die Datenbank zum ersten Mal bereitgestellt wurde, besteht die einzige Möglichkeit, Änderungen zu einem späteren Zeitpunkt bereitzustellen, darin, sie per Skript bereitzustellen. Ich hatte großes Glück, Vergleichs- / Bereitstellungsskripte mit SQL Compare von Red-Gate zu erstellen. Während Remus absolut Recht hat, ist diese Quellcodeverwaltung die beste Lösung dafür. In Wirklichkeit speichert die Quellcodeverwaltung normalerweise ein CREATE TABLESkript, das Sie nicht weit bringt, wenn Sie eine Spalte hinzugefügt und den Datentyp einer anderen Spalte geändert haben. Sie müssen noch eine Art Diff-Skript erstellen, das nur die Änderungen auf die Produktion anwendet, nicht die Tabelle löscht und neu erstellt.
Wenn Sie Dinge wie lokale Nachschlagetabellen haben, die sich in anderen Datenbanken befinden oder sich auf anderen Servern befinden könnten, sollten Sie Synonyme verwenden, anstatt diese Namen in Ihrem Code fest zu codieren. Dann müssen Sie nur sicherstellen, dass die Synonyme in jeder Umgebung korrekt sind, anstatt alle drei / vier Teilenamen in allen Ihren Modulen zu finden und sie bei der Bereitstellung zu aktualisieren. Wenn Sie lokale Dateipfade haben, die sich zwischen den Umgebungen unterscheiden, verwenden Sie eine zentrale Eigenschaftentabelle, anstatt diese Pfade in Ihre Prozeduren usw. fest zu codieren.
Theoretisch könnten Sie später eine Sicherungs- und Wiederherstellungsmethode verwenden, aber das funktioniert nicht gut, wenn die Produktionsdatenbank bereits verwendet wird. Es wird schwierig, eine Datenbank aus dem Test wiederherzustellen und keine der in der Produktion gesammelten Daten zu verlieren .