我正在編寫一個允許用戶將圖像上傳到服務器的應用程序。我預計每天大約20張圖像都是jpeg，可能不會進行編輯/調整大小。 （這是另一個問題，如何在存儲之前調整服務器端的圖像大小，也許有人可以在評論中這樣下載.NET資源）。 我現在想知道上傳圖片的最佳位置是什麼。什麼是存儲上傳圖像，SQL數據庫或磁盤文件系統的最佳地點？
將圖像作爲文件存儲在文件系統中，並在具有該圖像的確切路徑的表中創建記錄。或者，使用數據庫服務器的「圖像」或「二進制數據」數據類型將圖像本身存儲在表格中。
我看到兩者的優點和缺點。 我喜歡a），因爲我可以輕鬆地重新定位文件，只需更改表格條目。另一方面，我不喜歡在Web服務器上存儲業務數據，並且我不想將Web服務器連接到任何其他持有業務數據的數據源（出於安全原因） 我喜歡b）因爲所有的信息在一個地方，可以通過查詢輕鬆訪問。另一方面，數據庫很快就會變得非常大。外包數據可能會更困難。
我通常將文件存儲在文件系統上，因爲這就是它的存在，雖然也有例外。對於文件，文件系統是最靈活和最高效的解決方案（通常）。
有與存儲在數據庫中的文件的幾個問題 - 文件通常比一般的行大得多 - 包含許多大文件會消耗大量的內存結果集。另外，如果您使用使用表鎖進行寫入的存儲引擎（例如，ISAM），則您的文件表可能會經常被鎖定，具體取決於您在那裏存儲的文件的大小/速率。
關於安全 - 我通常將文件存儲在目錄是文檔根目錄（通過一個HTTP請求無法訪問）之外，並且通過第一爲適當的授權檢查腳本爲他們服務。
我們使用A.我會把它放在共享驅動器上（除非你不打算運行多個服務器）。
如果時間到了，這將不會爲您調整，那麼您可以調查緩存機制。
大多數的實現是選項A.
使用選B，你打開whoop4ss的一個整體的大罐，當你馬歇爾從數據庫中那些位到的東西，可以在瀏覽器上如果顯示...此外，數據庫關閉，圖像不可用。
我不認爲空間太大的問題的...... TB的硬盤是一對情侶，現在幾百美元。
我們正在與方案A執行，因爲我們沒有足夠的時間或資源做選項B.
的Flickr使用的文件系統 - 他們討論原因here
絕對，肯定選擇A.其他已經提到，數據庫通常不能很好地處理BLOB，無論它們是否設計爲這樣做。另一方面，文件系統則適用於這些東西。您可以選擇使用RAID分條，將圖像傳播到多個驅動器，甚至可以將它們分散到不同地理位置的服務器上。
另一個優點是您的數據庫備份/複製將是可怕的。
對於自動調整大小，請嘗試imagemagick ...它被用於許多主要的開源內容/照片管理系統......我相信它有一些.net擴展名。
我們有客戶堅持在幾個不同的後端幾次選項B（數據庫存儲），我們總是最終返回到選項A（文件系統存儲）。
即使通過SQL Server 2005，這是我們嘗試過的最新的一個，這樣的大型BLOB還沒有得到很好的處理。
具體來說，我們看到了嚴重的膨脹，我認爲可能會鎖定問題。
另外一個注意事項：如果你使用基於NTFS的存儲（Windows服務器等），你可能會考慮找到一種方法將成千上萬的文件放在一個目錄中。我不知道爲什麼，但有時文件系統不能很好地處理這種情況。如果有人對此有更多的瞭解，我很樂意聽到它。
但我總是嘗試使用子目錄來分解一些東西。創建日期往往很適合這樣的：
圖片/ 2008/12/17/.jpg文件
...這提供分離的體面水平，調試當中也有點幫助。如果有真正龐大的目錄，資源管理器和FTP客戶端都會窒息。
編輯：只是2017年的一個快照，在更新版本的SQL Server中，有很多新的選項可用來處理大量的BLOB，這些BLOB應該避免我討論的缺陷。
我在我的網站上使用上傳的圖片，我肯定會說選項a）。
我強烈建議的另一件事是立即將用戶命名照片的文件名更改爲更易於管理的內容。例如用日期和時間來唯一標識每張照片。
它也有助於去除用戶的任何奇怪字符的文件名，以避免未來的複雜化。
絕對調整圖像大小，如果可以，請檢查它的格式。有一些惡意文件被不知情的主機上傳並提供服務 - 例如，GIFAR漏洞使您可以將惡意Java小程序隱藏在GIF文件中，然後該文件可以讀取當前上下文中的Cookie並將它們發送到另一個用於跨站點腳本攻擊的站點。調整圖像大小通常可以防止這種情況發生，因爲它會傳播嵌入的代碼。雖然這種攻擊已被JVM修補程序修復，但天真地提供二進制文件而沒有對其進行清理會導致一系列的漏洞。
請記住，大多數病毒掃描程序只能運行在文件系統上 - 如果將二進制文件存儲在數據庫中，則無法輕鬆運行掃描程序。
我最近創建了一個PHP/MySQL應用程序，該應用程序將PDF/Word文件存儲在MySQL表中（目前每個文件大小爲40MB）。
優點：
缺點：
我會打電話給我的執行是成功的時候，它需要照顧的備份需求，簡化了項目的佈局。對於使用該應用程序的20-30人來說，表現很好。
選項A.
一旦加載圖像，你可以驗證格式和保存之前調整其大小。在http://www.codeproject.com有許多.Net代碼示例來調整圖像大小。例如：http://www.codeproject.com/KB/cs/Photo_Resize.aspx
如果它們是不需要編輯的小文件，則選項B不是一個錯誤的選項。我更喜歡編寫邏輯來存儲文件並處理瘋狂的目錄結構問題。有很多文件在一個目錄中是壞的。 EMKAY？
如果文件很大或需要不斷的編輯，尤其是像辦公室這樣的程序，那麼選項A是最好的選擇。
對於大多數情況下，這是一個優先選擇的問題，但如果選擇A，只需重新設置目錄中沒有太多文件。如果您選擇選項B，那麼使BLOBed數據表位於其自己的數據庫和/或文件組中。這將有助於維護，特別是備份/恢復。您的常規數據可能相當小，而隨着時間的推移，您的圖像數據將爲巨大的。
在SQL Server 2008中有一種稱爲filestream datatype的混合方法，在RunAs Radio #74上討論過，它有點像兩全其美。大多數人沒有2008年的情緒，但如果你這樣做，這個選項看起來很酷
出於安全原因，最好的做法是避免由IE's Content Sniffing造成的問題，這些問題可能允許攻擊者上傳JavaScript內部的圖像文件，這可能會在您的網站上下文中執行。因此，您可能需要在存儲圖像之前以某種方式轉換圖像（裁剪/調整它們）以防止此類攻擊。 This answer有一些其他的想法。
那麼，我有一個類似的項目，用戶上傳文件到服務器上。在我看來，選項a）是最好的解決方案，因爲它更加靈活。您必須做的是將圖像存儲在按子目錄分類的受保護文件夾中。主目錄必須由管理員設置，因爲內容必須不受運行腳本（非常重要）和（讀取，寫入）保護，以便在http請求中不可訪問。
我希望這可以幫助你。
選項B的唯一好處是在一個系統中擁有所有數據，但這是一個虛假的好處！您可能會爭辯說，您的代碼也是一種數據形式，因此也可以存儲在數據庫中 - 您希望如何？
除非你有一些獨特的案例：
這是沒有必要使用文件系統的文件保存。相反，你可以使用雲存儲（如Amazon S3）或基礎設施作爲一種服務在它的上面（如Uploadcare）：
https://uploadcare.com/upload-api-cloud-storage-and-cdn/
但在數據庫中存儲的文件是一個壞主意。
這基本上是我做的。
id將被一起存儲在數據庫中的任何行/文件內與image file name（或可能是隨機名稱作爲圖像名稱）。path文件夾如果不存在。例如2016/08/21。記住該路徑並將其存儲在數據庫中以獲取相同的文檔和行。id文件夾到path文件夾。 （路徑文件夾可能位於/ var/web-content文件夾中。）當你需要訪問一個文件中提及的任何圖像，你比包含圖像的文件夾的路徑和ID。例如/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg
這種方式，如果你必須刪除所有處理的圖像文件，只需刪除文件夾和它的內容遞歸。
這取決於您的要求，特別是音量，用戶和搜索頻率。但是，對於中小型辦公室來說，最好的選擇是使用Apple Photos或Adobe Lighroom等應用程序。它們專門用於存儲，編目，索引和組織這種資源。但是，對於需要大量存儲和大量用戶的大型組織，建議使用Nuxeo或Alfresco等數字資產管理實例化內容管理平臺;兩者都提供了非常好的資源，可以用簡化的方法來管理大量的數據，以便對其進行檢索。而且，非常重要的是：這兩個平臺都有一個免費（開源）選項。
我知道這是一箇舊帖子。但很多本頁面的訪問者沒有得到任何關於這個問題的信息。特別是對於新手。
如何上傳和存儲圖片或文件在我們的網站。
對於靜態網站也許沒有問題，因爲某些共享主機的文件存儲仍然充足。問題來自動態網站，當變大時。在數據庫中可以處理更大，但是圖像等文件中更大的問題。網站上有兩種類型的圖片：
圖片來自動態博客的管理員。通常，這些圖像在上傳之前已經過優化，當然。
允許用戶在用戶的情況下上傳圖片，例如頭像。或者用戶可以創建博客內容並從文本編輯器中放置一些圖像。這種圖像很難預測尺寸。用戶可以通過調整視圖大小來調整小圖片大小，但不能調整圖片大小。
由於忽略了以上項目1號，爲項目2號可以是暫時的通過以下提示解決，如果我們沒有在我們的網站上的圖像優化功能，快速的解決方案：
不要允許用戶通過將文本重定向到圖庫直接從文本編輯器上傳。在此頁面上，用戶必須提前上傳文件，然後才能嵌入內容。這種方法被稱爲文件管理器。
爲用戶使用裁剪圖像功能上傳圖像。這將限制圖片大小，即使用戶上傳非常大的文件。最終圖像是裁剪圖像的結果。我們可以在服務器端定義大小，只接受例如500Kb或更低。
現在，這只是暫時的。對於最終解決方案，問題重複：
我們能做的則：從份額VPS主機
遷移。不夠？然後通過升級到專用更高。
創建自己的文件存儲服務器。谷歌搜索做到這一點。這並不像你想象的那麼困難。有些人爲他們的網站做。
簡單的方法是使用CDN文件存儲服務。
好吧，1和2有點貴。但沒有3我認爲是最好的解決方案。
某些CDN服務允許您根據需要存儲您的網絡文件。問題，如何從我們的網站上傳文件到CDN？
不要擔心，一旦你註冊，通常是免費的，你會得到指導如何上傳文件，並從/到您的網站得到他們的鏈接。你會得到一個API和更多。這很容易。
有些提供商爲我們提供14天免費服務，存儲和帶寬有限。但是，這對起點是可以的。唯一的問題是因爲「人們從不嘗試」。
希望它會幫助新手。
這個問題在 – Draemon 2008-12-07 23:58:38
之前我沒有找到它，在哪裏？ – Tobias 2008-12-08 00:00:55
這裏http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay – 2008-12-08 02:15:05