我目前正在构建一个需要为每篇文章保存大量图片的CMS系统。我有很多问题： - ）
我需要以几种尺寸显示图片，包括或不包含水印。此外，我还需要原始图片，用于存档和管理目的。我现在想做的是将图片保存在数据库中，有两个版本：1。原始图片，2。网络优化版本。
保存表格中的所有图像非常方便。但它真的好主意吗？假设数据库中将包含数十万张图片，原始图片大小可能在3MB左右。因此db可以轻松达到100TB大小....这是非常好的策略吗？
另一方面，我为每张照片保存了一个较小的版本。此版本需要以几种尺寸显示，有水印和无水印。目前我认为在每个请求中都要考虑到这一点。请求将具有参数宽度，并根据此我可以决定大小和水印。 （我当然会缓存这项工作）。再次，这是一个好策略吗？它真的会起作用，或者这是非常昂贵的额外工作吗？
将此保存在数据库上真的更好吗？我的意思是对文章的每个请求，将需要大约50个对其图像的另一个请求，并且每个请求都需要打开/关闭到数据库的连接。
我将使用的技术：.net，sql-server 2008，NHibernate。
答案 0 :(得分：3)
最好的方法是将这些图像存储在文件系统中，并将数据存储在数据库中。由于性能和维护原因。在文件系统上备份和恢复会更容易，并且推动DBMS进行这样的工作并不是最好的想法，您需要将它们从db传输到应用程序然后推送到客户端。我只是相信这不是它的工作。把lighttpd守护进程或东西放到图像托管中，让它完成它的工作。
但是如果你喜欢这个想法，那么你将使用sql server 2008，你可以使用FILESTREAM将你的图像存储在你的表中。最终，它将在您选择的存储位置创建文件并将二进制数据存储在文件系统中，同时提供事务功能和数据完整性，这是一个很大的好处。看看那个选项。我记得，这表现良好，实际的数据库将非常紧凑。
关于动态调整大小，我说避免这样做。存储比CPU时间便宜，只需在上传时创建各种缩略图和水印版本，并将它们存储在某处，然后在需要时使用。不要一次又一次地执行相同的操作。您可以在第一次请求调整大小的版本时执行此操作，这样可以更容易地添加新版本或定期清除缓存以删除未使用的文件。您还可以只备份原始版本。
答案 1 :(得分：2)
将图像放入数据库有几个优点。我想到了ACID转移和备份一致性。如果你绝对需要，那么把图像放在数据库中。正如您所指出的，这需要付出代价：您需要一个庞大的数据库基础架构，如机器，许可证，运营团队。每次图像检索都是一项巨大的数据库I / O工作。
只需在数据库中存储元数据并将图像blob放在文件系统上，很多事情就会轻松得多。
达成决定的两种方法：
你绝对是什么样的杀手锏（绝对喜欢“如果我没有那个，整个事情根本不起作用”）需要从数据库中的图像方法？如果有的话，那就去吧
做一个背面的商业案例，计算数据库中图像方法的总成本（项目工作，基础设施，机器，许可证，操作），并将其与图像进行比较 - 文件系统方法。这应该给出一些如何进行的提示。