儲存影像 - 網絡桌面應用

相關： Storing Images in DB - Yea or Nay?儲存影像 - 網絡桌面應用

看完上面的問題後，似乎對圖像存儲與數據庫的首選方法是存儲在數據庫中唯一的文件路徑。但是，這些答案中的大部分似乎都集中在Web服務器上。

就我而言，我正在開發一個桌面應用程序，該應用程序將在Intranet中的多臺計算機上使用。專用服務器將託管數據庫，其中包含與在各種設備上執行測試有關的信息。

圖像需要以某種方式存儲在服務器上。在這種情況下，將圖像存儲在數據庫中是否是正確的方法，甚至是唯一的方法？

優點：

備份僅限於數據庫中。
無需打開服務器的文件系統到網絡。
用於服務器信息訪問的單一協議。
受保護的文件訪問。（用戶不能進去，並刪除所有圖像）

缺點

性能問題在未來如果有太多的圖像。

編輯：如標籤中所述，應用程序正在使用C＃/ .NET編寫。如果在這種情況下將圖像寫入文件系統是一個選項，我可以使用一些幫助瞭解如何完成此操作。在下面的評論中詳細闡述了一些內容，現在我假定一個MySQL數據庫，儘管SQL Server 2008的FileStream功能可能會改變這種情況。

同樣在我的情況下，圖像會經常被添加，並且在此之後可以被認爲是隻讀的，因爲它們不應該被改變，並且將在需要時被讀出。圖像可能會很小（每個〜70K），而且我還在考慮服務器上的其他二進制格式存儲，每個文件大約20K，我可能會應用相同的方法進行存儲和檢索。

來源

2009-12-07 Will Eddins

我認爲答案是，有沒有正確的答案。與編程（和生活）中的大多數事情一樣，它取決於。

以下是DB存儲的一些優點和缺點：

的觀光

輕鬆備份，管理和應用程序中的數據一站式的
更少依賴你應用和更少的移動部件。 KISS原則
在1GB以下的小文件上工作正常。
嘿，它是一個數據庫，所以可以在事務內完成保存，並在出現網絡問題時回滾
Sharepoint和TFS將所有內容都存儲在數據庫中，並且工作得很好。 甚至大男孩做
安全性可以通過應用程序很容易控制，不涉及文件/文件夾的權限

缺點

吃掉分貝空間
潛在影響性能如果沒有做好
如果總是存儲大文件（> 1GB），那麼這樣做不是一個好主意，除非在SQ中使用Filestream L服務器2k8
要求你實施一個體面的緩存策略（儘管你可能會想要這個）
文件系統感覺比數據庫更自然，更容易手動替換/查看文件。

我想當談到你的情況，我會傾向於簡單的存儲在DB。

來源

2009-12-15 21:20:08

爲了簡化應用程序，我同意這一點。我絕對不會有超過1GB的文件......對於這個問題，任何超過25kb的文件的可能性很小（灰度超聲圖像壓縮很好）。他們不可能在一年內使用1GB的數據。除此之外，性能不是一個大問題，因爲會有很少的查詢，其中大部分將在後臺進行。 – 2009-12-15 21:57:43

如果我可以選擇多個答案，我會，但這可能是我要去的。應用程序的簡單性與任何數據的小尺寸相結合似乎並不能證明Web /圖像服務器是合理的。如果表現是必要的，或者我有更多的數據，我可能會用pcampbell的方法去做，但Mark Ewer的經驗似乎也指出這對我們的需求來說已經足夠了。感謝大家。 – 2009-12-16 18:47:53

如果你可以使用SQL Server 2008，看看這個鏈接

Saving and Retrieving File Using FileStream SQL Server 2008

來源

2009-12-07 19:02:22

雖然還沒有確定，但我認爲他們傾向於MySQL，主要是由於成本。可能最多有兩個人同時訪問（讀取或寫入）數據庫，可能有5-10臺計算機連接到網絡。 – 2009-12-07 19:26:27

多少圖片，我們談論？他們經常獨特/更新嗎？如果不是，你可以將圖像打包到要分發給多臺計算機的客戶端上嗎？

就我個人而言，我會避免將圖像存儲在數據庫中，而是像您說的那樣存儲文件路徑。

如果你已經完成了所有的其他類似的問題（This，this和this）讀取，但都在問，如果這是一個好主意，那麼也許你的問題很不同，這將是一個好主意。

來源

2009-12-07 19:10:10

圖像是正在生成的測試結果的圖像。在這個特定的應用中，它們是由正在測試的設備生成的超聲波圖像，因此圖像必須存儲在其他人查看測試結果時才能被其他人查看。所以是的，它們是獨一無二的，許多圖像可能會在應用程序的整個生命週期中添加。你可不可以詳細說明如何在不存儲本地圖像的情況下使用「文件路徑」方法，就像在我的應用程序中那樣？ – 2009-12-07 19:14:59

我建議將這些文件保存在文件系統中的磁盤上，而不是數據庫中。文件系統的文件，關係數據數據庫等

通過Web服務交付

考慮通過宿主DB機器上的網絡服務/應用程序提供這些圖片到你的桌面應用程序。該應用程序的工作是隻提供圖像。使用ASP.NET應用程序在該機器上安裝Web服務器。有一個.ashx處理請求並傳輸二進制映像。事情是這樣的：

http://myserver/myapp/GetImage.ashx?CustomerID=123&ImageID=456

安全

如果內網安全是一個問題，這將是在那裏你可以確保用戶認證和授權的讀取訪問圖像的點。審計線索也可以在這裏實施。

文件系統的安全

關於對這些圖像的安全性，考慮到NTFS爲您提供了很多的措施，以確保只有那些誰被授權可以讀/刪除/放文件的要求。接下來的任務是定義這些角色並實現Windows安全組。

未來需要

這種方法可以讓你安全地從Intranet上的任何地方消耗這些圖像。也許這個應用程序在某個時候會被遷移到一個Web應用程序？客戶在Web解決方案適合的情況下是否可以提供功能請求？

這可能聽起來像是過度殺傷，而不是從數據庫中讀取blob，但從安全角度來看它很棒。考慮您的客戶和患者對隱私和安全的期望。

<%@ WebHandler Language="C#" Class="Handler" %> 

public class Handler : IHttpHandler { 

public void ProcessRequest (HttpContext context) 
{ 
    //go to the DB and get the path for this ID. 
    string filePath = GetImagePath(context.Request.QueryString["ImageID"]); 

    //now you have the path on disk; read the file 
    byte[] imgBytes=GetBytesFromDisk(filePath); 

    // send back as byte[] 
    context.Response.BinaryWrite(imgBytes); 
}

來源

2009-12-09 19:32:21

我想過這種可能性，本質上是創建一個用於下載和上傳圖片的Web服務，只需確保所有引用與數據庫保持同步即可。儘管如此，我仍然覺得這是一個更簡單的解決方案，因爲現在它增加了一個完整的Web服務器，而不是一個單獨的數據庫，以及只有Windows的可能需求。我不得不考慮的東西，謝謝你的想法。 – 2009-12-09 19:43:09

我沒有得到安全性的說法。數據庫中的安全性同樣容易完成，並且通過您的應用程序實際上可以更容易地進行管理。如果我有一個圖像垃圾負載，我不想管理文件存儲上的文件權限。我希望我的應用程序能夠處理安全性。我確實同意你的客戶端應用程序不應該知道它是如何獲取圖像的，所以最好將它從物理上或邏輯層抽象出來。 – 2009-12-15 21:24:49

是否需要downvote？距離評論時間戳約1分鐘。安全/日誌記錄/審計是答案中的一個特徵。 – 2009-12-15 21:56:13

如果你正在尋找替代品，我的最愛之一是一個十行的HTTP POST文件上傳處理器（PHP，.NET，Java等）+一個網絡服務器。當腳本驗證最大文件大小，並可能提取寬度爲&高度時，它會在數據庫中插入一行。檢索不需要通過腳本。標準文件託管將起作用。這將需要你打開80端口。你不需要用SOAP或其他任何東西來複雜化。常規的上傳處理程序可以完成這項工作。

接下來是WebDAV，沿着相同的路線。當然，用這種方法，你必須監視文件系統並相應地調整數據庫。您可以使用輪詢服務或掛接到文件系統事件。實際上，您也可以注入一個ISAPI篩選器或Apache處理程序來執行數據庫更新。

您可以使用FTP。爲ProFTPd添加一個擴展，它將更新數據庫並保持所有內容同步。

很多避免將圖像數據放入表格的方法。

如果您選擇數據庫解決方案，只需確保將BLOB分割爲單獨的表格。如果可以的話，單獨的表空間/設備/分區。或者，使用Oracle並忽略我所說的一切。

來源

2009-12-11 01:32:37 pestilence669

幸運的是，沒有用戶需要刪除1個條目，所以'DELETE FROM images'仍然不起作用。考慮到它是一小組使用該軟件的測試人員，它更多的是防止意外事故而不是真正的安全，而不是直接對文件系統進行讀/寫訪問。現在，他們沒有服務器。沒有Web應用程序。一切都在紙上，在這種方法中，仍然沒有web應用程序，只將當前正在紙上的內容移動到數據庫中，沒有其他任何東西需要備份。因此，雖然我知道數據庫中的圖像不好，但我正在尋找如何防止它，而不是未來最糟糕的情況。 – 2009-12-11 16:17:52

我不認爲這是圖像存儲的地方。選擇最簡單的方法即可。但是，如果證明是錯誤的，你應該有一個架構可以改變方法。

爲了實現這個目標，我會將數據和圖像存儲都放在Web服務接口後面。選擇一項技術 - 無所謂。所有對數據（和圖像）的訪問都是以同樣的方式 - 通過Web服務。

通過這樣做，您已將桌面應用程序的數據存儲位置分開。桌面應用程序不在乎。它只知道某個地址的服務器可以獲取數據。

然後將數據和圖像存儲在任何你想要的地方。爲你選擇最簡單的事情。如果最終出現問題，那麼（並且只有這樣）纔會增加額外的複雜性以解決問題。好消息是，額外的複雜性和工作完全不應該影響桌面應用程序。您可以在服務器上進行更改，而不必部署新版本的桌面應用程序。

來源

2009-12-11 17:00:02

從架構的角度來看，你會被拆分解決方案中獲得最佳性能分爲兩個部分：數據庫服務器，以及圖像服務器。

這樣做既可以保持較小的行大小，也可以將事務環境與內容分開。 SQL Server和mysql的關係數據庫將支持大BLOB，但並未針對它們進行優化。

大多數人將「圖像服務器」等同於「網絡服務器」，因爲它們在Web應用程序上工作，因此具有事實上的圖像存儲庫（本地磁盤上的目錄）。但是，這並不是就是。可以通過任何協議從任何位置提供圖像。

您提到了C＃/ .NET平臺和Intranet。我們可以假設一個Windows環境，可能是Active Directory？

如果是這樣，普通的香草文件服務器可能是您的圖像服務器。設置文件共享，爲此應用程序的所有用戶設置讀取/創建（但不修改/刪除）權限，將UNC路徑存儲在數據庫的某處（因此，如果您決定重新部署應用程序，則不必重新部署應用程序重新定位它），並讓您的客戶端應用程序使用像Guid這樣可靠的東西生成唯一的相對路徑。

它不像Web服務那樣優雅（這是我的首選方法），也不像純數據庫方法那樣免維護，但是我對此主題的印象是您的預算緊張交付截止日期短，而且Windows或NFS文件服務器的設置和維護（包括備份）比成熟的Web服務器更便宜，更輕鬆，更快速，因此它可能正是您在此尋找的內容。

大多數企業已經有一個文件服務器，所以通常這不需要任何新的基礎設施。但即使你不這樣做，我也看到文件服務器在舊的翻新工作站上運行 - 這不是花哨的，但是在低流量的環境下它完成了工作。

如果您選擇這種方法，我會建議在文件共享上使用某種目錄結構來簡化備份，歸檔等。例如：

\\ImageServer\MyAppRepository\yyyy-mm\{image-file-name-or-guid}.{ext}。

希望有所幫助。

來源

2009-12-12 00:16:54 Aaronaught

使用Amazon S3存儲爲您的圖片

只是存儲在數據庫中

亞馬遜的GUID或其他文件名是簡單，快速，價格便宜。安全等等等等

它倍的罰款，並可以選擇通過S3提供CDN像邊緣服務直接

存儲圖像在DB似乎總是隨着時間的推移變成一場噩夢

來源

2009-12-13 10:29:12 TFD

這些機器（包括服務器）都不能訪問互聯網，所以這似乎不是一種選擇。 – 2009-12-14 00:10:23

在我看來，那是你想要做什麼像Infovark做的事情。

他們用火鳥此，我給你一個鏈接火鳥storing image

來源

2009-12-14 22:28:45

我的公司開發了一個Windows窗體c＃應用程序，它將圖像存儲在數據庫中，並且工作得非常好。自2003年以來，我們一直在積極使用它，並且在系統中擁有大約150個演出數據。

首先，讓我說這不是最佳的性能架構。我們在保持數據庫統計信息保持最新並保持索引正確調整方面遇到了一些問題。我們基本上不得不每月重新索引系統。您需要知道，大多數RDBMS服務器的內置優化系統未針對大型二進制對象集合進行設置。

我們選擇將圖像放入數據庫的原因是因爲數據庫級複製。我們的系統分佈在五個州的七個辦事處，我需要將數據同步到每個站點。所以，我在每個站點和我們的公司辦公室之間固定了一個VPN，並在數據庫上設置了SQL合併複製。通過這種方式，我可以同時在辦公室之間打開一個頻道的同時同步數據和圖像。所以，我想說在大多數情況下，數據庫中的圖像並不是最佳解決方案，但是它符合我們的要求。

來源

2009-12-16 15:41:21

你應該嘗試MS SQl 2008，它帶有一個Type：FileStream，它可以自動將blob存儲在文件系統中。

來源

2009-12-16 15:43:51 Benny

儲存影像 - 網絡桌面應用

回答

相關問題