據我了解，互聯網環境中，大訪問量，數據庫速度和性能方面很重要。一般在數據庫存儲圖片的做法比較少，更多的是將圖片路徑存儲在數據庫中，展示圖片的時候只需要連接磁盤路徑把圖片載入進來即可。因為圖片是屬於大字段。一張圖片可能1m到幾m。
有個原則：圖片盡量不要存儲在數據庫中(是指不要二進制形式保存到字段，而只保存圖片的路徑)。這樣的大字段數據會加重數據庫的負擔，拖慢數據庫。在大並發訪問的情況下很重要。這是一個經驗。去看看dba對數據庫性能調優方面的分析都能得到這個答案的：就是圖片不要存儲在數據庫中。
二、數據庫中保存圖片路徑
一般是這樣子的：
按照年月日生成路徑。具體是按照年月日還是按照年月去生成路徑，根據自己需要(不一定是按照日期去生成)。
理解為什么要分散到多個文件夾中去才是關鍵，涉及到一個原理就明白了：
操作系統對單個目錄的文件數量是有限制的。當文件數量很多的時候。從目錄中獲取文件的速度就會越來越慢。所以為了保持速度，才要按照固定規則去分散到多個目錄中去。
圖片分散到磁盤路徑中去。數據庫字段中保存的是類似於這樣子的”images/2012/09/25/ 1343287394783.jpg”
原來上傳的圖片文件名稱會重新命名保存，比如按照時間戳來生成，1343287394783. jpg。這樣子是為了避免文件名重復，多個人往同一個目錄上傳圖片的時候會出現。
反正用什么樣的規則命名圖片，只要做到圖片名稱的唯一性即可。
比如網站的並發訪問量大，目錄的生成分得月細越好。比如精確到小時，一個小時都可以是一個文件夾。同時0.001秒有兩個用戶同時在上傳圖片(因為那么就會往同一個小時文件夾里面存圖片)。因為時間戳是精確到秒的。為了做到圖片名稱唯一性而不至於覆蓋，生成可以在在時間戳后面繼續加毫秒微秒等。總結的規律是，並發訪問量越大。就越精確就好了。
我現在還沒碰到需要這么精細的。概率比較少。
有個方面總結一下：為什么保存的磁盤路徑，是”images/2012/09/25/1343287394783.jpg”，而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面帶有斜杠)
我的理解：
連那個斜杠都不要。這里也是做到方便以后系統擴展。
在頁面中需要取出圖片路徑展示圖片的時候，如果是相對路徑，則可以使用”./”+”images/2012/09/25/1343287394783.jpg”進行組裝。
如果需要單獨的域名(比如做cdn加速的時候)域名，img1.xxx.com,img2.xxx.com這樣的域名，
直接組裝 “http://img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”
當然數據庫是可以在前面加斜杠/保存起來,/images/2012/09/25/ 1343287394783.jpg
其實不方便統一。比如相對路徑載入圖片的時候，則是”.”+” /images/2012/09/25/ 1343287394783.jpg”
可能我還沒體會到壞處，以后會遇到問題的。不過，遵循慣例不加斜杠” images/2012/09/25/ 1343287394783.jpg”就對了。
涉及到一個新問題：為什么大部分系統都不會域名保存進去，像這樣子http://www.xxx.com/images/2012/09/25/1343287394783.jpg保存到數據庫中
曾經與一個上海的網友聊天，他也是習慣不會把域名保存數據庫中過去。但當時我們兩聊的時候，他對”域名保存進去的做法”與”不保存域名進去”也沒有一個明確利弊。他就覺得，沒有什么明顯的區別啊。
了解的知識越多，越有利於我們做決定。可能就是一個”感覺區別不是很大”的影響下，去做一個決定，反而對后面是比較大的影響的。至少是增加自己的工作量了。
其實把域名保存進去，也不是什么滔天大罪的事情。但凡是經驗豐富的開發人員都不會這樣子做。這是一個經驗積累出來的，所以上海那個網友也對此並沒有明顯的概念很正常，他說他不知道cdn方面的(當然覺得存個域名進去沒什么大不了的)。需要了解cdn知識，什么情況下會用到cdn知識。
雖然是做開發人員，不需要關注運維和服務器之類的知識。不過了解一些就有利於理解了。
這里涉及到cdn加速。