在數(shù)據(jù)庫中放置圖像的優(yōu)點。
交易。當(dāng)您保存BLOB時，您可以像任何其他DB數(shù)據(jù)一樣提交它。這意味著您可以將BLOB與任何關(guān)聯(lián)元數(shù)據(jù)一起提交，并確保兩者是同步的。如果磁盤空間用完了呢？不承諾。文件沒有完全上傳？不承諾。愚蠢的應(yīng)用錯誤？不承諾。如果保持映像及其相關(guān)的元數(shù)據(jù)相互一致對您的應(yīng)用程序很重要，那么DB可以提供的事務(wù)可能是一件好事。
一個要管理的系統(tǒng)。需要備份元數(shù)據(jù)和BLOB嗎？備份數(shù)據(jù)庫。需要復(fù)制嗎？復(fù)制數(shù)據(jù)庫。需要從部分系統(tǒng)故障中恢復(fù)嗎？重新加載DB并向前滾動日志。DBS給一般數(shù)據(jù)帶來的所有優(yōu)點(卷映射、存儲控制、備份、復(fù)制、恢復(fù)等)適用于你的斑點。更一致，更容易管理。
保安。數(shù)據(jù)庫具有非常細(xì)粒度的安全特性，可以利用這些特性。模式、用戶角色，甚至是諸如“只讀視圖”之類的東西，以提供對數(shù)據(jù)子集的安全訪問。所有這些特性都適用于包含氣泡的表。
集中管理與#2相關(guān)，但基本上DBA(似乎沒有足夠的能力)可以管理一件事情：數(shù)據(jù)庫?，F(xiàn)代數(shù)據(jù)庫(特別是大型數(shù)據(jù)庫)可以很好地工作，可以跨幾臺機(jī)器安裝大型數(shù)據(jù)庫。單一的管理來源簡化了程序，簡化了知識轉(zhuǎn)移。
大多數(shù)現(xiàn)代數(shù)據(jù)庫都處理得很好。有了數(shù)據(jù)層中BLOB的一級支持，就可以輕松地將BLOB從DB流到客戶端。雖然有些操作可以同時“吸”整個BLOB，但如果您不需要該工具，那么就不要使用它。研究DB的SQL接口并利用它的特性。沒有理由把它們當(dāng)作“大字符串”，它們被一刀切地處理，然后把你的氣泡變成大的、記憶的、吞食的、高速緩存的炸彈。
就像您可以為圖像設(shè)置專用文件服務(wù)器一樣，您也可以在數(shù)據(jù)庫中設(shè)置專用的BLOB服務(wù)器。為它們提供專用磁盤卷、專用模式、專用緩存等。DB中的所有數(shù)據(jù)都不是相同的，行為也不一樣，沒有理由對其進(jìn)行完全相同的配置。良好的數(shù)據(jù)庫具有良好的控制水平。
從DB提供BLOB的主要NIT是確保HTTP層實際利用所有HTTP協(xié)議來執(zhí)行服務(wù)。
許多簡單的實現(xiàn)只是抓取BLOB，然后將它們從套接字中大量丟棄。但是HTTP有幾個非常適合流圖像的重要特性，特別是緩存頭、eTags和塊傳輸，以允許客戶端請求BLOB的“片段”。
確保您的HTTP服務(wù)正確地響應(yīng)了所有這些請求，并且您的DB可以是一個非常好的Web公民。通過將文件緩存到由HTTP服務(wù)器提供服務(wù)的文件系統(tǒng)中，您可以“免費”獲得其中的一些優(yōu)點(因為一個好的服務(wù)器無論如何都會對“靜態(tài)”資源這樣做)，但是要確保如果這樣做，就必須遵守修改日期等圖像的要求。
例如，有人請求Spaceeshuttle.jpg，這是2009年1月1日創(chuàng)建的圖像。最終緩存在請求日期的文件系統(tǒng)上，比如2009年2月1日。稍后，圖像將從緩存(FIFO策略或其他什么)中清除，稍后，有人在2009年3月1日再次請求它?，F(xiàn)在它有了2009年3月1日的“創(chuàng)建日期”，盡管它的創(chuàng)建日期實際上是1月1日。所以，您可以看到，特別是如果您的緩存發(fā)生了很大的變化，使用if修改的頭的客戶端可能會獲得比他們實際需要的更多的數(shù)據(jù)，因為服務(wù)器認(rèn)為資源已經(jīng)改變了，而實際上它沒有改變。
如果將緩存創(chuàng)建日期與實際創(chuàng)建日期保持同步，這可能會減少問題。
但關(guān)鍵是，要想成為一個“優(yōu)秀的網(wǎng)絡(luò)公民”，并為你和你的客戶節(jié)省一些帶寬等，就必須仔細(xì)考慮整個問題。
我剛剛為一個為DB提供視頻的Java項目進(jìn)行了所有這些工作，這一切都很好。
