将媒体文件（文档，视频，图像和最终可执行文件）存储在数据库本身是一种更好的做法，还是应该在数据库中放置一个链接并将它们存储为单独的文件？
答案 0 :(得分：4)
通过MS研究（对BLOB或不对BLOB）阅读this white paper - 它深入探讨了这个问题。
执行摘要 - 如果您有许多小（150kb或更少）文件，您可以将它们存储在数据库中。当然，这适用于他们正在测试的数据库并使用他们的测试程序。我建议全文阅读这篇文章，至少要对这种权衡有一个很好的理解。
答案 1 :(得分：1)
这是Oded与之相关的一篇有趣的论文 - 如果您使用的是带有FileStream功能的Sql Server 2008，结论就差不多了。我从链接的FileStream白皮书中引用了几个要点：
“FILESTREAM存储并非适用于所有情况。根据先前的研究和FILESTREAM功能行为，无法通过Transact-SQL访问的大小为1 MB或更大的BLOB数据最适合存储为FILESTREAM数据。”
“还必须考虑更新工作负载，因为对FILESTREAM文件的任何部分更新都将生成文件的完整副本。如果更新工作负载特别繁重，则性能可能会使FILESTREAM不合适”< / p>
答案 2 :(得分：1)
两个要求推动了您的问题的答案：
从一个数据库服务器中提取二进制文件的多个应用程序服务器确实阻碍了您扩展的能力。考虑到数据库连接通常 - 必然 - 来自比应用程序服务器的请求服务池更小的池。并且，数据卷二进制文件将消耗通过管道从数据库服务器发送到应用程序服务器。数据库服务器可能会对请求进行排队，因为它的连接池将被用于传递二进制文件。
流式传输很重要，因此在读取或写入时文件不完全在服务器内存中（看起来@ Andrew的答案有关SQL Server 2008的FILESTREAM可能会对此说话）。想象一个几千兆字节的文件 - 如果完全读入内存 - 就足以使许多应用程序服务器崩溃，而这些服务器只是没有物理内存来容纳。如果你没有流式数据库连接存储在数据库中真的不可行，除非你限制文件大小，使你的应用程序服务器软件分配至少与最大文件大小*请求服务连接数+一些额外的内存高架。
现在假设您没有将文件放在数据库中。大多数操作系统都非常擅长缓存经常访问的文件。因此，您可以获得额外的好处。另外，如果您正在使用Web服务器，他们非常擅长发送正确的请求标头，例如mime类型，内容长度，电子标签等等，否则您最终会自行编码。真正的问题是服务器之间的复制，但大多数应用程序服务器都非常擅长通过http - 流式读取和写入，并且另一个应答者指出保持数据库和文件系统同步备份。
答案 3 :(得分：0)
将BLOB数据存储在数据库中并不是正确的方法，除非它们非常小。而是存储他们的路径更合适。它将大大提高数据库查询和检索性能。
答案 4 :(得分：0)