在debug之前, 我們可能已經花費了大量精力去模擬正式服務器上出現的錯誤, 但最終發現這是由于正式服務器的settings文件設置和本地不同而 出現的問題. 這時你的心情會是怎樣?
當你在開發django項目時, 發現并修復了一個bug. 當將這一commit push到服務器后, 你突然發現這一bug的出現完全是因為你修改了本地的 settings文件而產生的, 而由于你的push, 又導致了服務器的宕機. 這時你又會是怎樣的感受?
每個人都會從另一個程序員那里拷貝/黏貼settings文件內容, 這難道不是違反了"不要重復自己"的原則嗎?

方案一
總是使用Django自帶的數據庫API。它會根據你所使用的數據庫服務器（例如PostSQL或者MySQL）的轉換規則，自動轉義特殊的SQL參數。這被運用到了整個Django的數據庫API中，只有一些例外：
傳給 extra() 方法的 where 參數。 (參考 附錄 C。) 這個參數故意設計成可以接受原始的SQL。
使用底層數據庫API的查詢。