存储图像：数据库或文件系统 -
我在这方面看了一些帖子，但我仍然不明白什么是最好的解决方案在我的情况。
我开始写一个新的Web应用程序和后端将可提供约1-10万的图像。 （平均粒径200-500kB单个图像）
存储图像：数据库或文件系统 -
我的网站将提供内容和图片来100-1000用户在同一时间。
我想也保持提供成本尽可能低（但这是次要的要求）。 我在想，如果与数据库大小相比，文件系统空间更便宜。
个人而言，我喜欢有我在数据库中的所有图像，但任何建议将非常感激:)
你认为在我的情况下，DB的做法是正确的选择的想法？
把所有这些图片在你的数据库将使它非常，非常大的。这意味着您的数据库引擎会忙于缓存所有这些图像（它并非真正为此设计的任务），而是可以缓存热应用程序数据。
保留文件缓存到OS和/或反向代理 - 他们将它更好。
如果您可以负担得起扩展，边缘服务器应该为您执行此操作。边缘服务器将运行在HTTP流量之外，因此除了初始请求以外，与映像来源无关，以及在超时之后发生的请求子集。考虑到这一点，最好的方式是构建自己的数据库层，以便它可以响应HEAD请求的正确信息，而无需访问保存“整个”图像的记录。磁盘通常更快，但选择数据库并不意味着您必须放弃所有的性能。 – 2012-04-27 14:34:02
当二进制对象处理，按照架构文档为中心的方法，而不是存储像PDF文件和图像数据库中的文档，你最终将有当你开始看到各种性能问题与数据库进行重构出来。只需将文件存储在文件系统中，并将路径放在数据库的表格中。数据类型的大小还有一个物理限制，您将用它来序列化并将其保存在数据库中。只需将其存储在文件系统中并访问即可。
这个问题每天都会被问到。 – 2009-08-05 16:09:00
你的第一句话说，你读过一些关于这个问题的帖子，所以我不会打扰投入链接到覆盖此文章。根据我的经验，根据您所发布的内容以及图像的数量和大小，如果将它们存储在数据库中，您将付出高昂的数据库性能。我会将它们存储在文件系统上。
我们使用FileNet，一种为图像优化的服务器。这个很贵。更便宜的解决方案是使用文件服务器。
请不要考虑在数据库服务器上存储大型文件。
正如其他人所提到的，存储对数据库中大文件的引用。
其他一些原因来存储文件系统上的图像：当数据库忙或向下
- 图片服务器甚至可以运行。
- 一些文件系统是存储文件制成，是在它非常有效。
- 将数据转储到您的数据库意味着更慢的备份和其他操作。
- 没有服务器端编码需要提供一个图像，只是普通的旧IIS/Apache。
- 您可以使用便宜的Web服务器或可能扩展到CDN的速度更快地扩展。
- 您可以在不涉及数据库的情况下执行相关工作（生成缩略图等）。
- 您的数据库服务器可以将更多的“真实”表数据保存在内存中，这是您获取数据库查询速度的地方。如果它使用宝贵的内存来保存图像文件的缓存，那么与内存中更多的照片索引相比，它几乎不会以任何速度购买任何东西。
您使用的数据库是？ MS SQL Server 2008提供了FILESTREAM存储
允许使用SQL Server 2008和NTFS文件系统的组合存储和有效访问BLOB数据。它涵盖了BLOB存储的选择，为使用FILESTREAM数据配置Windows和SQL Server，将FILESTREAM与其他功能组合的注意事项以及分区和性能等实施细节。
重复的http://stackoverflow.com/questions/1212832/most-efficient-way-to-store-a-20-meg-file-in-a-sql-server- 2005-image-column – andrewWinn 2009-08-05 18:25:55
重复？我使用的是Java，mysql和图像文件，它们是10MB的1/20 - 1/50。我的问题与特定技术无关，但需要存储的图像的大小/数量 – mickthompson 2009-08-05 22:37:32