數據庫遷移回滾的有用性

許多人在談論數據庫遷移，特別是關於其回滾的可能性。數據庫遷移回滾的有用性

我懷疑它是否有用，因爲db和model的模式與應用程序邏輯（MVC）緊密相連。

假設我已經完成了一些遷移的回滾。什麼？該應用程序將無法工作，因爲它的邏輯完全依賴於數據庫。

數據庫遷移的回滾能力的用例是什麼？

更新1

的主要問題

爲什麼回滾是作爲一個功能，當我需要改變的代碼？

我不創建遷移，像「add_another_field_to_table」。相反，每個遷移文件都完整描述了數據庫中的每個表。當我需要在我的數據庫中更改某些內容時，我只是更改遷移文件，但不會將其回滾到。

真的，如果我回滾遷移，它不會使我回到時間，就像版本控制一樣。我有很多工作，當計劃進行更改時，回滾沒有給我提供任何幫助。

來源

2010-09-27 AntonAL

「我沒有創建遷移，比如」add_another_field_to_table「，而是每個遷移文件都完全描述了數據庫中的每個表，當我需要更改數據庫中的某些內容時，我只是更改遷移文件」你能解釋一下這更進一步，因爲這聽起來很奇怪。當您需要添加列時，您不需要進行新的遷移，而是編輯舊的遷移？這聽起來像你沒有正確地使用遷移... – James 2010-09-27 08:56:42

是的，我也認爲。我沒有注意到部分遷移的好處。他們只是模糊了目前遷移過程中的大局。我知道，那個schema.rb文件就是爲了這個。但是，部分遷移只會減慢我的工作速度，因爲當我需要查看數據庫中的某個表時，我需要跳過幾個「add_column_to_table」遷移文件。但是，他們的真正好處是什麼？我還不知道答案... – AntonAL 2010-09-27 09:05:12

回滾點在於您同時回滾代碼和數據庫。該場景是您在生產服務器上升級您的代碼和數據庫，然後發現錯誤並確實需要返回。因此，回滾您的代碼並使用您的向下遷移來回滾您的數據庫。

來源

2010-09-27 08:13:02 James

真的不明白你的問題，但我試着解釋一下回滾。如果您想通過相應的遷移撤消更改，則執行回滾。這意味着數據庫將被修改，並且您的schema.rb將自動重新生成。當你這樣做時你可能也想刪除引用代碼。例如，如果您從模型中刪除了一個字段，可能您不希望在您的代碼中引用該屬性。如果你嘗試訪問，那麼會給你未定義的屬性異常。而已。例如，如果您之前創建了一些模型10遷移，並且您想要更改某些字段，可能會變得有點麻煩。最好創建一個新的遷移並在那裏修改，而不是回滾到相應的遷移。

更新1

閱讀您的更新，我想喲不要用遷移的主要優勢，靈活性。但是，您的解決方案提供了有關數據庫情況的更多概述。如果你喜歡這樣做，我建議按順序進行以下步驟。

回滾到相應的遷移。（rake db:migrate VERSION=XXX，我喜歡例如更好rake db:rollback STEP = 2，回滾2遷移，STEP可選）
進行更改
遷移數據庫更新所有的表格，並獲得當前的遷移版本。（rake db:migrate）

此功能不會影響您的模型或其他內容，只需更改遷移文件，重新生成schema.rb並更改數據庫結構，而不是其他任何操作。不能像版本控制系統那樣執行代碼回滾，並且沒有意義做類似的事情。你必須小心不要使用刪除的字段。例如，如果您的comment表中有user_id，則可以將其稱爲模型comment_instance.user_id中的一個屬性，Rails在數據庫字段和模型屬性之間具有自動映射。希望這是有道理的。

來源

2010-09-27 08:22:19 dombesz

我認爲一個理解，什麼是遷移是關於。他們將數據保存在生產服務器的數據庫中。我可以在不觸及其他表格中的數據的情況下進行小修改。我對嗎？ – AntonAL 2010-09-27 09:23:42

那麼，如果你像你一樣使用你的遷移，你也必須在你的生產模式中執行這3個步驟（步驟1,3也可以），但這有點不好意思，這就是爲什麼你在改變時使用新的遷移數據庫，在更新生產模式中的更改時也可以使這些黑客無效。無論如何，您不需要像組織那樣使用遷移，您的表的字段可以在不同的遷移中，因爲schema.rb不會丟失。如果你需要桌子的結構，你可以從那裏得到。 – dombesz 2010-09-27 09:40:23

Up遷移有什麼意義？

您創建表結構。
你對它進行編碼，效果很好。
你把網站投入生產，大家都很開心。
哦，等等，他們需要一個新功能，包括將列添加到現有表。

你是如何處理這個問題的？您必須在開發表中添加一列，測試代碼，更新現場而不忘記同時更新現場數據庫（如果您這樣做，將會出現大錯誤）並且還要保留現有的實時數據。如果沒有像rails這樣的好管理解決方案，數據庫管理的這一方面可能是一個真正的痛苦。

所以......

代碼一個行遷移，增加了一列
運行遷移上開發的副本，scehma.rb將更新
代碼的新功能，如果你需要檢查DB架構使用schema.rb不是遷移文件。

現在你準備好發佈生產....

更新代碼對生產
運行遷移生產。 Rails將自動計算出需要應用的內容併爲您完成！

當然，在添加一列的時候，並不是你自己搞混亂。

但是如果有3位程序員全部添加了遷移呢？如果你有很多活網站，所有版本都不一樣？那個活網站2或17遷移落後了嗎？我需要做些什麼才能使數據庫保持最新的代碼，同時保留實時數據？你能否看到這很快就會讓人感到困惑？

Rails遷移（實際上每個遷移系統的工作原理都相同）旨在使更新DB結構變得非常簡單。值得正確使用。

來源

2010-09-27 09:31:48 James

考慮使用capistrano來部署站點併爲每個部署創建時間戳快照的場景。通過使用文件夾和遷移的時間戳，您可以確定代碼和模式的哪些版本齊頭並進行回滾。

一個git倉庫會給你類似的選項。

當然，真正的問題是，一旦網站的用戶開始添加數據，那麼這些數據可能會被清除，除非您在回滾之前將其備份，並在以後的日子裏精心恢復。

來源

2010-09-27 09:41:23

我發現回滾只有在本地完成時纔有用，也就是說，當您正在處理新的代碼時。一旦遷移到您的版本控制系統，如果您意識到存在一個錯誤，那麼它並沒有真正的回滾遷移，因爲其他開發人員已經將遷移拉下來並運行，所以您需要告訴他們回滾 - 這太難以管理，也讓你看起來無能爲力:)

在這種情況下更好的做只是做另一個遷移來解決問題，然後每個人（包括你的生產服務器）只是堅持隨着&遷移系統。

來源

2010-09-27 11:18:01

我同意這似乎是最常見的用例。與OP一樣，我也看不到主要數據庫回滾過程的真正好處。大多數正常的模式更新都是非破壞性的設計，因爲消費的生產軟件在應用更新時不得中斷。因此，即使您必須回滾生產代碼，通常也可以保留更新的模式，如有必要，只需應用一些額外的遷移，而不是回滾並重新應用原始遷移的修改版本。 – 2016-04-09 21:49:52

在處理遷移代碼和最終提交之前，我使用本地遷移回滾rake db:migrate:redo。

來源

2010-09-27 11:42:11 gertas

數據庫遷移回滾的有用性

回答

相關問題