臨時存儲圖像直到創建數據庫實體的最佳實踐是什么？

Question

我正在使用ASP.NET 4.0，並且已經有一個代表單個業務實體的大型Web表單。 用戶可以上傳與實體關聯的多個圖像。 提交表單后，將創建實體並為其分配GUID。 文件將存儲到文件系統。

問題在於，在將實體插入數據庫后，我們必須使用分配給實體的GUID來命名文件。 因此，在單擊“提交”按鈕之前，我們將有幾個圖像文件處於混亂狀態。

這個問題有很明顯的答案-將圖像保存到文件系統，然后在創建業務實體時重命名這些文件。 但是，我相信必須有非常強大的模式和幾個關鍵細節，才能構成一個非常強大的系統。 這種情況下的最佳做法是什么？

Answer 1

GUID的優點之一是可以在任何地方創建它們。 因此，讓您的應用創建並分配GUID，然后使用預先分配的GUID在實體上執行插入。 然后，您的應用程序將具有用於命名文件的GUID。

如果這不可行，那么您的重命名方案對我來說似乎是最好的選擇。

Answer 2

正如您提到的“非常強大的系統”，我只是在寫這篇文章：

我會嘗試阻止維護除數據庫（包括文件系統）之外的任何狀態，因為從長遠來看，這會增加維護的復雜性。 無論如何，您都必須清理文件，我更希望從數據庫中清理文件。 文件系統（在大多數情況下）並不理想，因為它不是：

• 跨多個前端服務器，因此擴展性較差
• 交易性操作（大部分時間）
• 當您還原數據庫備份時，文件也將位於“ Limbo”中

也許這並不是您真正要尋找的答案，因為您可能無法更改需求（對不起，如果不是這樣的話），但是正如您提到使系統“非常強大”一樣，我認為這可能是相關的。

如果您使用的是SQL 2008，請查看FILESTREAM： http : //technet.microsoft.com/zh-cn/library/bb933993.aspx

Answer 3

就個人而言，我將避免將上載保存在文件系統中，而是將其移動到數據庫中。 這樣一來，您在備份和災難恢復計划中就省去了更少的資源，從而減少了復雜性並減少了維護。 我過去的做法是，將文件上傳后保存在文件服務器上，然后在提交並接受表單后將它們復制到DB，然后從文件系統中刪除它。 也將有一個常規的維護腳本來清除所有孤立文件的“ limbo”文件夾。