我們有大約100個數據庫遷移文件。他們中的許多人進行了不可逆的架構更改。還有一些後來的遷移會更改或刪除在早期遷移中創建的表。我們有很多數據庫遷移文件 - 我們應該保留它們嗎?
我們直接從schema.rb文件創建新的數據庫,所以我們想知道是否有任何理由保留整套遷移?
我們將創建一個基於我們現有的schema.rb的新遷移。
我們有大約100個數據庫遷移文件。他們中的許多人進行了不可逆的架構更改。還有一些後來的遷移會更改或刪除在早期遷移中創建的表。我們有很多數據庫遷移文件 - 我們應該保留它們嗎?
我們直接從schema.rb文件創建新的數據庫,所以我們想知道是否有任何理由保留整套遷移?
我們將創建一個基於我們現有的schema.rb的新遷移。
是的,你提出的建議被認爲是最佳實踐。
我已經用我的舊應用程序多次完成此操作。您需要在某個地方支持您的遷移,直到您滿意爲止,當然,這是應用程序維護的重要組成部分 - 如果您有很多舊遷移,則可能需要永久執行db:reset
或運行一個新的開發環境。
我專門使用rake db:setup
和rake db:reset
(從來沒有rake db:migrate
)在生產服務器或新開發機器上安裝新數據庫。這些命令已經使用schema.rb
或structure.sql
重新創建數據庫。
也就是說,製作schema.rb
的副本非常簡單,將其作爲新的起點並刪除所有舊的遷移。
我更喜歡爲了歷史目的而保留我的遷徙,但這是一個品味問題。
我們已經嘗試在某處討論過這個問題 - 您是否知道任何詳細瞭解rails /數據庫最佳實踐的網站或資源? – roo 2012-02-17 02:12:58
@roo我見過一些「最佳實踐」網站,但沒有一個專門針對這個問題。我在一次當地的黑客馬拉松中與一些Rubyists同行討論這個問題後,把它作爲一種最佳實踐加以考慮;幾乎不科學,但肯定是同行評審。 :)如果我認爲這個案例是最佳實踐,那麼我認爲將任何代碼庫(包括遷移)混淆在一起是沒有意義的,因爲沒有人可以使用它。如果有人想爲自己的教育閱讀數據庫歷史記錄,Git會爲您提供覆蓋;沒有理由在工作分支。 – 2012-02-17 04:17:42
是的,我們也得出了相同的結論。很高興知道其他人進行了同樣的談話:) – roo 2012-02-17 04:26:17