我一直在使用south，但我真的很討厭重新手動遷移數據，即使我爲一個類做了一個小小的更新。如果我不使用Django，我可以很容易地改變表格模式，並在課堂上進行調整，我很好。大型網站在使用Django時如何處理即時模式更改？
我知道大多數人可能會提前正確地思考架構方式，但實際上有些時候您需要立即進行更改，並且我認爲使用south非常適合此操作。
是否有某種人們使用的高級方法，甚至可能修改Django本身的核心？或者有什麼關於south，我不只是grokking？
我真的很討厭重新手動遷移數據，即使我對一個類做一個小小的更新。
您可以指定什麼樣的更新？如果你的意思是增加新的字段或編輯現有的字段，顯然是的。如果你的意思是修改在字段上操作的方法，那麼不需要遷移。
我知道，大多數人可能會告訴我正確地想出來的架構方式提前
這肯定會幫助想好了幾次。經驗也有幫助。但顯然你無法預見一切。
但實際上有些時候您需要立即進行更改，我不認爲使用南方是最理想的選擇。
老實說，我並沒有被這種說法說服。如果可以使用SQL「立即」部署更改，那麼我認爲可以使用South部署它們。特別是如果你已經使用Fabric等自動化你的部署。
而且我覺得很難相信，所花費的時間使用生成的腳本可以比先寫相應的SQL，然後執行它花費的時間顯著更大的執行遷移。根據我的經驗，至少這種情況並非如此。
唯一的例外可能是一種情況：ORM不容易有對SQL的等價物。在這種情況下，您仍然可以通過您的（南）遷移腳本執行原始SQL。
或者南方有什麼我不只是grokking？
我懷疑你是不是有所著的Grokking有序，版本控制，可逆遷移的想法。只有SQL的遷移並不總是被設計爲可逆的（我知道有例外）。除非開發者特別關心如何保持它們，否則它們不是有序的。我甚至看到人們在生產過程中可能會引發麻煩的更新，甚至沒有暫停先開始事務，然後在沒有記錄SQL的情況下放棄SQL。
我不是在質疑你的技能或注意細節在這裏;我只是指出我認爲你與南方的斷開。
希望這會有所幫助。