SQL三種東西永遠不要放到數據庫裏

SQL三種東西永遠不要放到數據庫裏

圖片，文件，二進制數據

既然數據庫支持BLOB類型的數據，把文件塞進BLOB字段裏必定沒有錯了！？錯，不是這樣的！別的先不提，在不少數據庫語言裏，處理大字段都不是很容易。

把文件存放在數據庫裏有不少問題：

• 對數據庫的讀/寫的速度永遠都趕不上文件系統處理的速度
• 數據庫備份變的巨大，愈來愈耗時間
• 對文件的訪問須要穿越你的應用層和數據庫層

這後兩個是真正的殺手。把圖片縮略圖存到數據庫裏？很好，那你就不能使用nginx或其它類型的輕量級服務器來處理它們了。

給本身行個方便吧，在數據庫裏只簡單的存放一個磁盤上你的文件的相對路徑，或者使用S3或CDN之類的服務。

短生命期數據

使用狀況統計數據，測量數據，GPS定位數據，session數據，任何只是短期內對你有用，或常常變化的數據。若是你發現本身正在使用定時任務從某個表裏刪除有效期只有一小時，一天或數週的數據，那說明你沒有找對正確的作事情的方法。使用redis， statsd/graphite， Riak，它們都是幹這種事情更合適的工具。這建議也適用於對於收集那些短生命期的數據。

固然，用挖土機在後花園裏種土豆也是可行的，但相比起從儲物間裏拿出一把鏟子，你預定一臺挖土機、等它趕到你的園子裏挖坑，這顯然更慢。你要選擇合適的工具來處理手頭上的事。

日誌文件

把日誌數據存放到數據庫裏，表面上看起來彷佛不錯，並且「未來也許我須要對這些數據進行復雜的查詢」，這樣的話很得人心。這樣作並非一個特別差的作法，但若是你把日誌數據和你的產品數據存放到一個數據庫裏就很是很差了。

也許你的日誌記錄作的很保守，每次web請求只產生一條日誌。對於整個網站的每一個事件來講，這仍然會產生大量的數據庫插入操做，爭奪你用戶須要的數據庫資源。若是你的日誌級別設置爲verbose或debug，那等着看你的數據庫着火吧。

你應該使用一些好比Splunk Loggly或純文本文件來存放你的日誌數據。這樣去查看它們也許會不方便，但這樣的時候很少，甚至有時候你須要寫出一些代碼來分析出你想要的答案，但總的來講是值得的。

但是稍等一下，你是那片不同的雪花，你遇到的問題會如此的不一樣，因此，若是你把上面提到的三種東西中的某一種放到了數據庫裏也不會有問題。不，你錯了，不，你不特殊。相信我。