我需要能够将多个文件上传到数据库，并将它们与给定表中的给定记录相关联。我最初考虑压缩所有必要的文件，并将生成的字节数组作为参数与剩余的记录数据一起发送到存储过程，这样我就可以确定这是一个单独的事务，并检索所有相关的文件给定的记录将是一块蛋糕。但是，由于性能原因，此计划未被接受，现在我有两个选择：
创建一个包含byte[]数组的数据结构，（二进制 - ）序列化它并将其与数据一起发送;或
首先发送剩余数据，捕获记录的ID并单独发送每个文件（将其与给定ID相关联）;
现在，1）看起来太像我的第一个计划，很可能会被拒绝，即使这次不涉及压缩。选项2）似乎是要走的路，但是，我必须保证我在单个事务中上传记录的数据和文件，这将迫使我在数据层中进行更改（尽管很轻微）。
如果您遇到此问题，您会选择哪个选项？如果我上面没有说过哪一个，那么呢？
编辑：数据库位于远程服务器中。文件可以任意大，但我不认为它们比1-2MB大。将文件存储在应用程序和数据库服务器都可访问的位置不是一个选项，因此我不能只将文件的路径发送到数据库（它们必须真正存储为数据库中的BLOB）。
答案 0 :(得分：1)
由于性能问题，您的第一个计划遭到拒绝 - 可能这意味着网络传输速度？
您的替代计划是单独发送文件＆amp;然后将它们绑在一起放在服务器上。这是一个很好的计划，但您希望确保在单个事务中上传和提交所有文件。接下来，在收到所有文件并成功提交之前，您的服务器无法响应成功信号。
因此，您的第二个方案需要在事务中上载相同数量的数据。那怎么能更好地表现呢？
事实上，您可以提出的任何可能的设计 - 假设需要在单个交易中接收文件 - 将具有相同的“性能问题”。
您对“交易”的理解可能与我不同，但通常在交易完成之前您无法使用最初提交的“剩余数据”。我认为您的问题围绕着系统所需的“单一事务”性质，而不是任何网络瓶颈。
答案 1 :(得分：0)
我们根据当时的需求和文件的预期大小使用两种不同的方案：
1）我们将文件流式传输到接收系统，并将它们缓存在接收系统上的一个众所周知的位置（即使用GUID作为文件名的临时目录）。这可以异步完成以提高性能。您需要在与文件关联的记录中提供可用的引用（例如GUID），以便接收系统可以找到该文件。当记录被写入数据库时，我们将文件内容流式传输到参数（存储过程参数）中，以便在最短的时间内将其存储在内存中。
2）如果文件相对较小，我们会将它们流式传输到记录中的字节数组中。这当然是最容易实现的，但如果您的文件很大，那么在“通过线路”发送记录时，您将失去对性能的一些控制。