我正在构建一个asp.net mvc应用程序，用户可以将图片附加到他们的个人资料中，也可以在系统的其他区域附加，例如仪表板上显示最近消息的消息小工具等。
当用户上传这些内容时，我想知道将它们存储在数据库或磁盘上是否更好。
数据库优势
易于备份整个数据库并保留配置文件内容/图像以及相关的个人资料/用户表
当我稍后在轨道上构建Web服务时，他们可以从一个位置（数据库）中提取所有与profiile相关的数据
文件系统优势
从磁盘加载文件可能更快
任何其他优势？
其他网站在哪里存储此类信息。对于类似这样的事情我是否有点担心数据库性能？
也许会有一种方法来缓存从数据库中提取的图像一段时间？
或者，将这些图像存储在数据库中的想法如何，但是将它们复制到磁盘，以便Web服务器可以从那里加载它们？这似乎既提供了Db的备份和便利，同时又提供了磁盘上文件的速度优势。
有问题的基础设施
摘要
在SO上阅读很多相关的线程，很多人现在都趋向于SQL Server Filestream类型。然而，从我可以收集的内容（我可能是错的），当文件非常小时，没有太大的好处。但是，当文件是多个MB或更大时，文件流看起来会大大提高性能。
由于我的个人资料图片往往约为5kb，我决定将它们作为varbinary（max）保存在数据库的文件存储中。
在ASP.NET MVC中，我确实看到了一些性能问题，返回FileContentResults这样从数据库中拉出的图像。所以如果在我的应用程序缓存中找不到该文件的位置，我最终会在磁盘上缓存该文件。
所以我想我选择了混合动力车;
在任何时候我都可以删除磁盘上的缓存文件夹，并且当重新请求图像时，它们将在第一次点击时重新复制，然后从缓存中提供。
答案 0 :(得分：4)
实际上，除非您使用高度优化的文件系统引擎，否则根据您拥有的图像数量，您的数据存储区查找数据库实际上可能会更快。数据库设计用于快速查找，并使用比文件系统更有趣的技术。
reiserfs（已废弃）对查找非常棒，zfs，xfs和NTFS都有很棒的哈希算法，linux ext4看起来也很有希望。
在块读取方面，对系统的命中不会有任何不同。问题是什么是更快的查询查找返回文件名（可能是一个哈希？）反过来使用单独的open，filesend close访问？或者只是将blob倾倒出去？
有几件事要考虑，包括网络命中，处理命中，可分发性等。如果你将东西存储在数据库中，那么你可以移动它。然后再次，如果您将图像存储在内容传送服务上，因为您没有对自己进行任何网络点击，可能会更快。
考虑一下，记住一点基准测试从来没有伤害过任何人:-)所以用典型的数据集大小测试一下，并考虑同步查询等问题。
答案 1 :(得分：4)
存储对数据库中文件的引用并将文件本身存储在磁盘上。
这种方法更灵活，更容易扩展。
您可以拥有一个数据库和多个服务于静态内容的服务器。让几个数据库完成这项工作会更加棘手。
Flickr以这种方式工作。
希望它有所帮助。