將文件上傳到數據庫

Question

我需要能夠將多個文件上傳到數據庫，並將它們與給定表中的給定記錄相關聯。我最初想到了壓縮所有必要的文件，並將結果字節數組作爲參數連同剩餘的記錄數據一起發送到存儲過程，這樣我就可以確定這起到單個事務的作用，並且檢索所有關聯的文件與給定的記錄將是一塊蛋糕。然而，這一計劃不被接受性能方面的原因，現在我有兩種選擇：

1. 創建一個數據結構，它包裝的byte[]陣列，（二進制）序列化，並與發送沿數據;或

2. 先發送剩餘的數據，獲取記錄的ID並單獨發送每個文件（將其與給定的ID相關聯）;

現在，1）看起來太像我的第一個計劃，並有可能即使這次沒有壓縮將參與被拒絕。選項2）似乎是要走的路，但是，我必須保證我將記錄的數據和文件都上傳到單個事務中，這將迫使我在數據層中進行更改（儘管很輕微）。

如果您遇到此問題，您會選擇哪個選項？如果沒有上述那些，那麼哪一個呢？

編輯：數據庫位於遠程服務器中。這些文件可以是任意大的，但我不認爲它們比1-2MB大。將文件存儲在應用程序和數據庫服務器均可訪問的位置不是一種選擇，因此我不能將路徑發送到數據庫的文件（它們必須真正作爲BLOB存儲在數據庫中）。

Answer 1

你的第一個計劃由於性能問題而被拒絕 - 大概這意味着網絡傳輸速度？

您的備用計劃是單獨發送文件&然後將它們綁定在您的服務器上。這是一個很好的計劃，但您希望確保所有文件都在一次交易中上傳並提交。從那以後，您的服務器在收到所有文件併成功提交之前無法用成功信號做出響應。

所以你第二個場景需要在交易中上傳相同數量的數據。那麼它將如何能夠更好地執行？實際上，任何可能的設計（假設需要在單個事務中接收文件）都會產生相同的「性能問題」。

您可能對我的「交易」有不同的理解，但通常您不能去使用最初提交的「剩餘數據」，直到交易完成。我認爲你的問題是圍繞着你的系統所要求的「單一事務」性質，而不是任何網絡瓶頸。

Answer 2

我們使用兩種不同的場景爲這個取決於我們當時的需求和文件的預期大小：

1）我們的文件流式傳輸到接收系統，並讓他們在一個衆所周知的位置緩存在接收系統上（即使用GUID作爲文件名的臨時目錄）。這可以異步完成以提高性能。您需要在與文件關聯的記錄中提供可用參考（如GUID），以便接收系統可以找到該文件。當記錄正在寫入數據庫時​​，我們將文件內容傳送到參數（存儲過程參數）中，以便它在存儲器中保存最短的時間。

2）如果文件相對較小，我們會將它們串流到記錄中的一個字節數組中。這當然是最容易實現的，但是如果您的文件很大，在通過「線路傳送」發送記錄時，會失去對性能的一些控制。