處理開發和產品之間的模式變更

這可能是一種愚蠢的做事方式，但這是我公司的職責所在......我們在開發中進行模式更改，隨後我們必須使用最新版本進入生產。因此，我們手動打開生產SQL 2008數據庫，使用設計器進行相關修改，部署新代碼，然後希望最好。有時我們忘記在產品模式上做出改變，這顯然會導致嚴重的頭痛。那麼，肯定有更好的方法？理想情況下，我們希望有一些免費工具來幫助我們識別和部署模式更改，但我不知道存在這樣的情況......處理開發和產品之間的模式變更

我們在VS2010中使用ASP.NET，如果這樣做有所幫助。

來源

2011-01-05 Headache

參見Writing and Changing Database Code。

來源

2011-01-05 23:16:34

我主張爲upgrade scripts。作爲升級腳本，每總要部署，不管多麼微小。然後，在轉入生產時，只需將升級腳本從版本N運行到版本N + 1即可。有效地禁止所有'可視'數據庫設計/管理工具。

在這個方向上有很多努力，代碼優先ORMs，database GDR project,diff based部署等等。就我個人而言，從長遠來看，我認爲明確的升級腳本是更好的選擇。

來源

2011-01-05 23:17:16

VS2010的模式比較工具怎麼樣：http://www.mssqltips.com/tip.asp?tip=2089它似乎可以只是比較dev和prod模式，並給我一個自動升級腳本？ – Headache 2011-01-05 23:49:40

這是VS GDR，由vsdbcmd支持：http://msdn.microsoft.com/en-us/library/dd193283.aspx。當我使用一個基於diff的工具時，我的問題就開始了，它無意中提供了通過SELECT ... INTO和sp_rename修改表（這是大多數diff工具的一個技巧）。除表格有160Bn行，磁盤上有1.5Tb。這就是爲什麼我更願意使用升級腳本，所以我確切知道會發生什麼。此外，腳本被簽入到源代碼控制中，並且我可以有變化的歷史記錄。 – 2011-01-06 00:14:43

如果你簡單地將開發差異化（考慮到該工具做了一個完美的工作），那麼最終你會得到任何你當前的開發者。根據變更追蹤的問題和變更的歷史記錄，你假定*沒有開發者曾犯過任何錯誤，並將其留給dev db *。 – 2011-01-06 00:16:36

我相信Team Foundation Server有一種方法可以在每次構建時存儲和釋放數據庫模式更改。除此之外，我同意Remus Rusanu。所有更改都必須編寫腳本並放入與每個應用版本一起發佈的版本腳本中。

來源

2011-01-05 23:21:39

處理開發和產品之間的模式變更

回答

相關問題