改進你的系統的最好的方法是先避免做「蠢事」。 我並不是說你或你開發的東西「蠢」，只是有些決定很容易被人們忽略掉其暗含的牽連， 認識不到這樣做對系統維護尤其是系統公升級帶來多大的麻煩。
作為乙個顧問，像這樣的事情我到處都能見到，我還從來沒有見過做出這樣的決定的人有過好的結果的。
，檔案，二進位制資料
既然資料庫支援blob型別的資料，把檔案塞進blob欄位裡一定沒有錯了！？錯，不是這樣的！ 別的先不提，在很多資料庫語言裡，處理大字段都不是很容易。
把檔案存放在資料庫裡有很多問題：
• 對資料庫的讀/寫的速度永遠都趕不上檔案系統處理的速度
• 資料庫備份變的巨大，越來越耗時間
• 對檔案的訪問需要穿越你的應用層和資料庫層
這後兩個是真正的殺手。
把縮圖存到資料庫裡？很好，那你就不能使用nginx或其它型別的輕量級伺服器來處理它們了。
給自己行個方便吧，在資料庫裡只簡單的存放乙個磁碟上你的檔案的相對路徑，或者使用s3或cdn之類的服務。
短生命期資料
使用情況統計資料，測量資料，gps定位資料，session資料，任何只是短時間內對你有用，或經常變化的資料。 如果你發現自己正在使用定時任務從某個表裡刪除有效期只有一小時，一天或數週的資料， 那說明你沒有找對正確的做事情的方法。 使用redis，statsd/graphite， riak，它們都是幹這種事情更合適的工具。 這建議也適用於對於收集那些短生命期的資料。
當然，用挖土機在後花園裡種土豆也是可行的，但相比起從儲物間裡拿出一把鏟子， 你預約一台挖土機、等它趕到你的園子裡挖坑，這顯然更慢。 你要選擇合適的工具來處理手頭上的事。
日誌檔案
把日誌資料存放到資料庫裡，表面上看起來似乎不錯，而且「將來也許我需要對這些資料進行複雜的查詢」， 這樣的話很得人心。這樣做並不是乙個特別差的做法， 但如果你把日誌資料和你的產品資料存放到乙個資料庫裡就非常不好了。
也許你的日誌記錄做的很保守，每次web請求只產生一條日誌。 對於整個**的每個事件來說，這仍然會產生大量的資料庫插入操作， 爭奪你使用者需要的資料庫資源。 如果你的日誌級別設定為verbose或debug，那等著看你的資料庫著火吧。
你應該使用一些比如splunk loggly或純文字檔案來存放你的日誌資料。 這樣去檢視它們也許會不方便，但這樣的時候不多，甚至有時候你需要寫出一些**來分析出你想要的答案， 但總的來說是值得的。
可是稍等一下，你是那片不一樣的雪花，你遇到的問題會如此的不同， 所以，如果你把上面提到的三種東西中的某一種放到了資料庫裡也不會有問題。 不，你錯了，不，你不特殊。相信我。
英文原文：three things you should never put in your database
三種東西永遠不要放到資料庫裡
frank wiles 發表了一篇博文，frank wiles曾在很多演講裡說過，改進你的系統的最好的方法是先避免做 蠢事 並不是說你或你開發的東西 蠢 只是有些決定很容易被人們忽略掉其暗含的牽連，認識不到這樣做對系統維護尤其是系統公升級帶來多大的麻煩。作為乙個顧問，像這樣的事情我到處都能見到，我還...
三種東西永遠不要放到資料庫裡
檔案，二進位制資料 既然資料庫支援blob型別的資料，把檔案塞進blob欄位裡一定沒有錯了！錯，不是這樣的！別的先不提，在很多資料庫語言裡，處理大字段都不是很容易。把檔案存放在資料庫裡有很多問題 這後兩個是真正的殺手。把縮圖存到資料庫裡？很好，那你就不能使用nginx或其它型別的輕量級伺服器來處理它...
三種東西永遠不要放到資料庫裡
frank wiles 發表了一篇博文，frank wiles曾在很多演講裡說過，改進你的系統的最好的方法是先避免做 蠢事 並不是說你或你開發的東西 蠢 只是有些決定很容易被人們忽略掉其暗含的牽連，認識不到這樣做對系統維護尤其是系統公升級帶來多大的麻煩。作為乙個顧問，像這樣的事情我到處都能見到，我還...