因爲我已經被告知不要存儲數據庫，或任何與此有關的大BLOB上的圖像的年齡。雖然我可以理解爲什麼數據庫不是/沒有效率，因爲我從來不明白爲什麼他們不能。如果我可以把文件放在某個地方並引用它，爲什麼數據庫引擎不能做同樣的事情。我很高興Damien Katz在最近Stack Overflow播客中提到它，並且Joel Spolsky和Jeff Atwood至少默默地同意了這一點。
我一直在閱讀微軟SQL Server 2008應該能夠有效處理BLOB的提示，這是真的嗎？如果是這樣，那麼在什麼地方阻止我們將圖像存儲在那裏並擺脫一個問題呢？我能想到的一件事是，雖然圖像可以很快地由靜態Web服務器提供，但如果它位於某個文件的某個位置，則當它位於數據庫中時，它必須從數據庫傳輸到Web服務器應用程序（這可能比靜態Web服務器），然後它被服務。不應該緩存幫助/解決最後一個問題？
是的，的確，SQL Server 2008只是實現了一個像你提到的功能，它被稱爲文件流。如果你確定你只想爲你的應用使用SQL Server（或者願意爲性能付出代價或者在新的開發之上開發一個類似的層），那麼在數據庫中存儲blob確實是一個很好的論點。 DB服務器）。儘管我預計類似的圖層會在不存在於不同的數據庫服務器時開始出現。
像往常一樣，真正的好處取決於特定的場景。如果您將提供大量相對靜態的大文件，那麼考慮到性能/可管理性組合，此場景加緩存可能是最佳選擇。
This white paper描述了SQL Server 2008的FILESTREAM功能，該功能允許使用SQL Server 2008和NTFS文件系統的組合存儲和有效訪問BLOB數據。它涵蓋了BLOB存儲的選擇，爲使用FILESTREAM數據配置Windows和SQL Server，將FILESTREAM與其他功能組合的注意事項以及分區和性能等實施細節。
這是一個很好的答案，我想我應該刪除我的，鎖定你進入NTFS和複雜的實現細節非常痛苦，但我可以想到一些可能需要它的解決方案。 – 2009-07-01 22:29:11
SQL Server中有一些選項可用於管理存儲大型數據塊的位置，這些數據塊自SQL2005起至今一直存在，因此我不知道爲什麼無法存儲大型BLOB數據。例如，MOSS會將您上傳的所有文檔存儲在SQL數據庫中。
當然有一些性能影響，就像任何事情一樣，所以你應該注意，如果你不需要它，不要檢索blob，也不要將它包含在索引等中。
文件流在2008年是新的。文件流確實對普通的varbinary產生了巨大的影響，請檢查我的答案中的鏈接。 – 2009-07-01 22:28:53
是的，他們會是最好的。但MOSS（Microsoft Office Sharepoint Server）安裝在SQL 2005上，它將文檔存儲在數據庫中，因此在2005年必須有功能。 – 2009-07-02 00:09:50
只因爲你可以做點什麼並不意味着你應該這樣做。
如果你關心效率，你仍然很可能不想爲任何足夠大規模的文件服務做到這一點。
另外它看起來像這個話題已深入討論......
之一古典原因對在數據庫中存儲BLOB謹慎的是，數據將被存儲和事務控制，這意味着該DBMS需要確保它可以回滾變化下編輯（改變），和在崩潰後恢復更改。這通常是通過對事務日誌主題的一些變化來完成的。如果DBMS要將更改記錄在2 GB的blob中，那麼它必須有一種方法來確定發生了什麼變化。這可能是簡單的（前圖像和後圖像）或更復雜的（某種二進制增量操作），這在計算上更昂貴。即便如此，有時最終的結果將是千兆字節的數據通過日誌存儲。這會傷害系統性能。有多種方法可以限制更改的影響 - 減少流經日誌的數據量 - 但有一些折衷。
在數據庫中存儲文件名的代價是數據庫管理系統在文件更改時沒有控制權（一般情況下），因此數據的再現性受到損害;你不能保證DBMS之外的某些東西沒有改變數據。 （這個論點有一個非常普遍的版本 - 你不能確定有人一般沒有篡改數據庫存儲文件，但我指的是在數據庫中存儲一個文件名，引用一個不受DBMS。由DBMS控制的文件受到無特權的偶然更改的保護）。
新的SQL Server功能聽起來很有趣。我還沒有探究它的作用，所以我不能評論它避免或限制上面提到的問題的程度。
我會盡量分解你的問題，並儘可能地處理你的各個部分。
SQL Server 2008和文件流類型 - 上面Vinko的回答是到目前爲止我見過的最好的一個。文件流類型是SQL Server 2008是您正在尋找的。 Filestream在版本1中，所以如果對於企業應用程序，我仍然不推薦使用它，但仍有一些原因。作爲一個例子，我的回憶是，你不能跨多個Windows UNC路徑拆分底層物理文件的存儲。遲早會成爲企業應用的一個非常嚴重的限制。
在數據庫中存儲文件 - 在這個宏偉的方案中，Damien Katz的原始方向是正確的。大多數大型企業內容管理（ECM）播放器將文件存儲在RDBMS中的文件系統和元數據上。如果你做得更大，查看亞馬遜的S3服務，你就會看到帶有非關係數據庫後端的物理文件。除非你在數十億的存儲空間中測量你的文件，否則我不會推薦走這條路線並自己動手。
有關數據庫中文件的更多詳細信息 - 乍一看，很多事情都代表着數據庫中的文件。一個是簡單性，二是交易完整性。由於Windows文件系統不能在事務中入伍，因此需要在數據庫和文件系統中發生的寫入需要內置事務補償邏輯。直到我與DBA交談之前，我並沒有真正看到故事的另一面。他們通常不喜歡混合的業務數據和blob（備份變得痛苦），所以除非你有一個單獨的專用於文件存儲的數據庫，否則這個選項通常不會吸引DBA。你說得對，數據庫會更快，所有其他的事情都是平等的。不知道你的應用程序的用例，我不能多說緩存選項。可以這麼說，在許多企業應用程序中，文檔上的緩存命中率太低以至於無法緩存它們。
希望這會有所幫助。
相關：http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay – 2009-07-01 22:20:35
類似：http://stackoverflow.com/questions/815626/to-do-or不在數據庫中存儲圖像 還有很多其他的。 – 2009-07-01 22:35:04