Không, không có gì sai khi sử dụng bản sao lưu để triển khai ban đầu , thực tế tôi sẽ nói rằng đây thường là cách an toàn nhất để làm điều đó. Thực sự không có bất kỳ sự "ô nhiễm" nào có thể xảy ra trừ khi bạn có những thứ được mã hóa cứng như tên máy chủ hoặc tên cơ sở dữ liệu khác với sản xuất so với trong môi trường thử nghiệm.
Mặc dù sao lưu / khôi phục (giống như tập lệnh DDL của riêng bạn bị giới hạn trong cơ sở dữ liệu) sẽ không mang theo những thứ như thông tin đăng nhập cấp máy chủ, máy chủ được liên kết, công việc Tác nhân SQL, v.v.
Có một số lợi ích phụ khác mà bạn nhận được với bản sao lưu mà bạn không nhất thiết phải có với tập lệnh DDL, ví dụ: nếu bạn đã tạo bảng gốc như thế này:
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
);
Tất cả các ràng buộc này có tên do hệ thống tạo ra, như PK__foo__DE90ECFFA28BBAB8. Khi bạn chạy cùng một tập lệnh này trong sản xuất, tên sẽ khác, trừ khi bạn viết kịch bản định nghĩa bảng chính xác từ môi trường kiểm tra. Điều này có thể gây ra sự cố sau này nếu bạn tạo tập lệnh thả / tạo / thay đổi từ kiểm tra và cần chạy chúng trong sản xuất.
Bạn cũng sẽ nhận được tất cả dữ liệu trong các bảng tra cứu, v.v. khi bạn sao lưu, bạn sẽ phải tạo tập lệnh theo cách thủ công để đưa dữ liệu đó vào sản xuất. (Mặc dù bạn phải chắc chắn xóa mọi dữ liệu thử nghiệm mà bạn không muốn sản xuất.)
Và một điểm yếu của việc tự viết kịch bản này là bạn phải đảm bảo tất cả các đối tượng được tạo theo thứ tự phụ thuộc chính xác. Bạn có thể có các phụ thuộc tại chỗ trong thử nghiệm bị thiếu trong sản xuất vì các đối tượng không được tạo theo đúng thứ tự.
Khi nói đến nó, một bản sao lưu chỉ sạch hơn. Và bạn nên kiểm tra cơ sở dữ liệu khi nó được triển khai, vì vậy bạn sẽ tìm thấy bất kỳ "ô nhiễm" nào khá nhanh và sửa chúng trong cả hai môi trường.
Khi cơ sở dữ liệu ban đầu được triển khai, rõ ràng cách duy nhất để triển khai các thay đổi vào một ngày sau đó là kịch bản chúng. Tôi đã rất may mắn khi tạo các kịch bản so sánh / triển khai bằng cách sử dụng So sánh SQL của Red-Gate. Mặc dù Remus hoàn toàn đúng, nhưng kiểm soát nguồn đó là giải pháp tốt nhất cho vấn đề này, trong thực tế, kiểm soát nguồn thường sẽ lưu trữ một CREATE TABLEtập lệnh, điều này không giúp bạn tiến xa khi bạn đã thêm một cột và thay đổi loại dữ liệu của cột khác - bạn vẫn cần xây dựng một số loại kịch bản lệnh khác nhau sẽ chỉ áp dụng các thay đổi cho sản xuất, không bỏ và tạo lại bảng.
Nếu bạn có những thứ như bảng tra cứu cục bộ trong các cơ sở dữ liệu khác hoặc có thể ở các máy chủ khác nhau, thì thay vì mã hóa cứng các tên đó trong mã của bạn, bạn nên sử dụng từ đồng nghĩa. Sau đó, bạn chỉ phải đảm bảo các từ đồng nghĩa là chính xác trong từng môi trường, thay vì tìm tất cả ba / bốn tên phần trong tất cả các mô-đun của bạn và cập nhật chúng khi triển khai. Và nếu bạn có các đường dẫn tệp cục bộ khác nhau giữa các môi trường, hãy sử dụng bảng thuộc tính trung tâm thay vì mã hóa cứng các đường dẫn đó vào quy trình của bạn, v.v.
Về lý thuyết, bạn có thể sử dụng phương pháp sao lưu và khôi phục sau đó nhưng nó không hoạt động tốt nếu cơ sở dữ liệu sản xuất đã được sử dụng - thật khó để khôi phục cơ sở dữ liệu từ kiểm tra và không mất bất kỳ dữ liệu nào được thu thập trong sản xuất .