在SQL數據庫中存儲大量文本（例如html頁面）是一個好主意嗎？或者，將它作爲html文件存儲在文件系統中是否更好？SQL中的大文本和圖像
圖像也是一樣 - 將圖像數據存儲在數據庫中還是更好地將它們放在磁盤上是一個好主意？
存儲大量數據會導致性能問題嗎？每種存儲方式有哪些優缺點？
就數據大小而言，在這種情況下，我正在尋找HTML和圖像大小小於500kb的圖像（可能要小很多）。足以產生您的平均文章/博客條目/等等比例的網頁。
在數據庫中存儲二進制數據（文檔，圖像等）有一些優點。
您可以在與要存儲的文檔信息（名稱，日期等）相同的事務中提交文檔本身的更新。這意味着你不必擔心編寫你自己的兩階段提交（儘管ISTR SQL Server 2008爲此提供了一個解決方案）。
您可以一次備份整個地段（文件和元數據），而不必擔心到數據庫與文件系統同步
可以提供非常簡單地在.NET Web服務的文件，因爲他們直接進入DataTables，並且通過將DataTables放入DataSet並傳遞它，毫不費力地序列化。
您可以將數據庫安全性應用於對象，就其他數據而言，無需擔心網絡文件的權限。
它也有一些缺點，太：
備份可以得到非常大的
在數據庫中的二進制對象的大小可以比文件就更大了不少最初來自於，因此在客戶端 - 服務器環境中，它可能增加在網絡上打開它們所花費的時間。
根據應用程序的不同，如果需要提供大量大型文檔，您可能需要考慮數據庫服務器上的負載。
所有這一切說，這是一種我廣泛使用的技術，它工作得很好。
你放得越多，你將會移動得越多，因此你將會創造更多的開銷。
如果你有一個很棒的web服務器，當你可以將所有的壓力委派給web服務器時，沒有任何理由將任何額外壓力添加到數據庫中。
即使從維護的角度來看，移動和處理文件在一個很好的邏輯結構，而不是與數據庫不斷的工作更容易。
這是一個大小問題。這取決於你的圖片/文字真的有多大。
將這些值存儲在數據庫中比基於文件系統的方法有許多優點，但在某個點它變得效率低下。例如，我不會在數據庫中存儲極高分辨率的圖像。
所以這是一個學位問題，而這又意味着答案取決於您的硬件資源和系統架構。所以我不相信你的問題有一個正確的答案。也許你可以告訴我們更多關於你想要存儲的東西的細節以及你的服務器的外觀。
我認爲你可以爭論任何一方，但我在大量文字的一邊是可以的（因此可以搜索），但圖像應該作爲單獨的文件存儲在數據庫中的鏈接。儘管可能，我從未想出任何令人信服的理由將圖像存儲在數據庫中。
當我用PHP編程時，這是我的一個難題。在數據庫中存儲blob等圖像可以更容易地管理安全和權限，但代價高昂。 我總是用來在數據庫上存儲一些元數據和文件系統上的二進制內容。訪問圖像不是直接的（<img src="image/path" />），而是由PHP腳本提供的，它們在顯示圖像之前通過會話檢查用戶身份驗證和授權（<img src="showimage.php?id=$id" />）。我建議你這樣做（無論你在哪種應用程序中工作）。
還有一件事要考慮的是這些大塊的文本和圖像多久會發生變化。數據更改是導致分段的原因。碎片可能發生在數據文件和數據庫結構中。文件系統比數據庫更適合處理碎片。文件更改越頻繁，系統將會越快分解。
存儲文本數據庫
是的，你應該儘可能多的HTML內容，你可以=>它簡化了備份存儲到數據庫中。您應該使用模板系統，以便您不會將整個網頁結構存儲在每個文檔中，只需將不同頁面之間的內容存儲到數據庫中即可。
實際上，我們部署的大多數網站都不超過10MB的文本內容（我們使用自己的自定義模板系統）。純文本的10MB是很多的內容（信不信由你）文件系統上
存儲照片
一般情況下，它只是一個壞主意來存儲在數據庫中的圖像，因爲你失去交換能力用FTP快速拍照。
維護將會更容易。徽標，文章照片和支持圖形在網站的整個生命週期中都會發生很大的變化。與文本不同，您不能將照片的二進制數據完全剪切粘貼到數據庫編輯器中。如果您的數據庫遭到破壞 - 發生的次數往往不是這樣，那麼如果您遇到麻煩將圖像存儲在數據庫中。而文件系統損壞隻影響有限數量的文件。數據庫損壞會發送給你一個備份，這是一個時間吸引。