将文件上传到数据库

Question

我需要能够将多个文件上传到数据库，并将它们与给定表中的给定记录相关联。我最初想到了压缩所有必要的文件，并将结果字节数组作为参数连同剩余的记录数据一起发送到存储过程，这样我就可以确定这起到单个事务的作用，并且检索所有关联的文件与给定的记录将是一块蛋糕。然而，这一计划不被接受性能方面的原因，现在我有两种选择：

1. 创建一个数据结构，它包装的byte[]阵列，（二进制）序列化，并与发送沿数据;或

2. 先发送剩余的数据，获取记录的ID并单独发送每个文件（将其与给定的ID相关联）;

现在，1）看起来太像我的第一个计划，并有可能即使这次没有压缩将参与被拒绝。选项2）似乎是要走的路，但是，我必须保证我将记录的数据和文件都上传到单个事务中，这将迫使我在数据层中进行更改（尽管很轻微）。

如果您遇到此问题，您会选择哪个选项？如果没有上述那些，那么哪一个呢？

编辑：数据库位于远程服务器中。这些文件可以是任意大的，但我不认为它们比1-2MB大。将文件存储在应用程序和数据库服务器均可访问的位置不是一种选择，因此我不能将路径发送到数据库的文件（它们必须真正作为BLOB存储在数据库中）。

Answer 1

你的第一个计划由于性能问题而被拒绝 - 大概这意味着网络传输速度？

您的备用计划是单独发送文件&然后将它们绑定在您的服务器上。这是一个很好的计划，但您希望确保所有文件都在一次交易中上传并提交。从那以后，您的服务器在收到所有文件并成功提交之前无法用成功信号做出响应。

所以你第二个场景需要在交易中上传相同数量的数据。那么它将如何能够更好地执行？实际上，任何可能的设计（假设需要在单个事务中接收文件）都会产生相同的“性能问题”。

您可能对我的“交易”有不同的理解，但通常您不能去使用最初提交的“剩余数据”，直到交易完成。我认为你的问题是围绕着你的系统所要求的“单一事务”性质，而不是任何网络瓶颈。

Answer 2

我们使用两种不同的场景为这个取决于我们当时的需求和文件的预期大小：

1）我们的文件流式传输到接收系统，并让他们在一个众所周知的位置缓存在接收系统上（即使用GUID作为文件名的临时目录）。这可以异步完成以提高性能。您需要在与文件关联的记录中提供可用参考（如GUID），以便接收系统可以找到该文件。当记录正在写入数据库时​​，我们将文件内容传送到参数（存储过程参数）中，以便它在存储器中保存最短的时间。

2）如果文件相对较小，我们会将它们串流到记录中的一个字节数组中。这当然是最容易实现的，但是如果您的文件很大，在通过“线路传送”发送记录时，会失去对性能的一些控制。