将文件存储在数据库中，而不是文件系统？
一般来说，性能问题有多糟糕，是将文件存储在数据库（特别是mssql）中，而不是文件系统？ 我不能想出应用程序可移植性之外的原因，我想将我的文件作为varbinaries存储在SQL Server中。
看看这个答案：
在DB中存储图像 – 是或否？
从本质上讲，空间和性能的影响可能相当大，这取决于用户的数量。 另外，请记住，Web服务器很便宜，您可以轻松地添加更多来平衡负载，而数据库通常是最昂贵和最难扩展部分Web体系结构的。
有一些相反的例子（例如，微软的Sharepoint），但通常，在数据库中存储文件不是一个好主意。
除非可能的话，你写的桌面应用程序和/或大致了解你将有多less用户，但像一个公共网站随机和不可思议的东西，你可能会付出高昂的代价存储在数据库中的文件。
如果你可以迁移到SQL Server 2008，那么你可以利用FILESTREAM支持，这两种支持都是最好的 – 文件存储在文件系统中，但是数据库集成比在varchar字段中存储文件path要好得多。 您的查询可以返回一个标准的.NET文件stream，这使得集成更简单。
FILESTREAM存储入门
我会说，这取决于你的情况。 比如我在地方政府工作，我们有很多像mugshots等的图片。我们没有很多的用户，但是我们需要对数据有很好的安全性和审计。 数据库对我们来说是一个更好的解决scheme，因为它使这更容易，我们不会遇到扩展问题。
这里有什么问题？
现代DBMS SQL2008有多种处理BLOB的方法，它们不仅仅是粘在一个表中。 当然，有利有弊，你可能需要更深入的思考。
这是一个有趣的论文，由已故的（？）吉姆·格雷（Jim Gray）撰写
BLOB或不BLOB：数据库或文件系统中的大型对象存储
我们将其存储在数据库中，这里是详细分析为什么它更好。
巨大的文件存储在数据库而不是文件系统
根据我自己的经验，将文件存储为文件总是更好。 原因是文件系统针对文件存储进行了优化，而数据库则没有。 当然，也有一些例外（例如，预计下一代MS文件系统应该build立在SQL服务器之上），但总的来说，这是我的规则。
虽然性能是一个问题，我认为现代数据库devise已经使小文件的问题less得多。
除了性能，还取决于数据是多么紧密耦合。 如果文件包含与数据库字段密切相关的数据，那么它在概念上属于靠近它的数据，并可能存储在一个blob中。 如果它包含可能与多个logging相关的信息，或者可能在数据库的上下文之外使用，则它属于外部。 例如，网页上的图像是从链接到该页面的页面的单独请求获取的，因此它可能属于外部（取决于具体的devise和安全性考虑因素）。
我们的妥协，我不承诺这是最好的，一直存储在数据库中的小XML文件，但外面的图像和其他文件。
我们决定将其存储为http://www.freshlogicstudios.com/Products/Folders/ varbinary以预期性能问题。 我可以说，我们已经惊喜地发现它的效果。
我赞同@ZombieSheep。 还有一件事 – 我通常不认为数据库实际上需要可移植性，因为你错过了DBMS供应商提供的所有function。 我认为迁移到另一个数据库将是人们考虑的最后一件事情。 只是我的$ .02
必须将blob（图像）parsing为字节数组然后将其写入到磁盘中，然后将其写入到正确的文件名中，然后读取这些数据开销足以阻止您经常这样做，特别是如果文件是相当大。
不要模糊或任何东西，但我认为你将要存储的“文件”types是最重要的决定性因素之一。 如果你基本上谈论一个可以存储为文件的大型文本字段，那么我的首选项将用于数据库存储。
