我正在为我的网站添加一些功能，以便用户可以上传他们自己的个人资料图片，所以我想知道是将它们作为BLOB存储在数据库中，还是将它们放在文件系统中。
我在这里找到了一个与此类似的问题：Storing images in DB: Yea or Nay，但给出的答案更多地针对那些期待数千甚至数百万图像的人，而我更关心的是小图像（JPEG可能是150x150像素），其中数量很少：可能高达一两千个。
对于这种情况，DB BLOB vs Filesystem有什么感受？客户端如何使用DB缓存来自文件系统的映像？
如果存储在数据库中的BLOB是可行的方法 - 我应该知道 存储它们的任何内容吗？由于我想我的大多数用户都不会上传图片，我是否应该在需要时创建一个user_pics表到（外部）加入常规users表？
编辑：我正在重新打开这个问题，因为它不是您链接到的那两个副本。这个问题具体是关于使用DB或FS来处理少量图像的优缺点。正如我上面所说，另一个问题是针对那些需要存储成千上万张大图像的人。
答案 0 :(得分：7)
回答部分问题：
客户如何使用来自DB和文件系统的缓存图像？
对于数据库：在数据库中有一个last_modified字段。使用Last-Modified HTTP标头，以便客户端的浏览器可以正常缓存。当浏览器请求图像“如果更新”（无法回想起它的内容;某些HTTP请求标题）时，请务必发送相应的响应。
对于文件系统：做同样的事情，但文件修改时间。
如果存储在数据库中的BLOB是可行的方法 - 我应该知道在哪里存储它们吗？由于我想我的大多数用户都不会上传图片，我是否应该在需要时创建一个user_pics表到（外部）加入常规用户表？
我会将BLOB和相关的元数据放在自己的表中，它与您的用户表之间存在某种关系。这样做可以更轻松地优化数据的表存储方法，使事情更加整洁，并为可扩展性留出空间（例如一般的“文件”表）。
答案 1 :(得分：1)
我曾经遇到类似的问题，对于pdf文件使用小型DMS。该场景与您的场景不同：最多可能是100个文件，每个文件的大小最多为10 MB - 而不是您对个人资料图片的期望。但朋友给我回答的答案也适用于你的情况：
将每个存储系统用于其设计目的。
将数据存储在数据库中。将文件存储在文件系统中。
这不是最终答案（*），但对于初学者来说这是一个很好的经验法则。
我从未听说过Windows FS缓慢且有时不可靠，正如Aaron Digulla在他的回答中所述。如果有这样的问题，这肯定需要考虑在内。但对于头像图片，它并没有让我觉得重要。
（*）我知道，我知道，42 ......
答案 2 :(得分：0)
从服务它们的角度来看，更方便的是，编写代码来为它们服务，备份程序等等？你想要正确的答案，而不是其他人的正确答案。
答案 3 :(得分：0)
从我的观点来看，数据库之外的任何内容都应该留在外面。它可能是文件系统或单独的表，您不会每天复制或备份。它使数据库变得更轻，它变得更慢，更容易理解和维护。
如果您使用的是MSSQL，请确保blob存储在单独的数据文件中。不像其他一切主流。
答案 4 :(得分：0)
在Windows上，尽可能多地放入数据库。文件系统有点慢，有时甚至不可靠。
在Linux上，您有更多选择。在这里，您应该考虑将大文件移动到文件系统中，并将名称保留在数据库中。如果你使用像Ext3或ReiseFS这样的现代文件系统，你甚至可以创建许多具有相当好性能的小文件。
您还需要考虑如何访问数据。如果你拥有数据库中的所有内容，那么你有一个访问路径，不必担心另一组权限，但你必须处理读/写BLOB的额外复杂性。在许多DB中，无法搜索BLOB。
在文件系统上，您可以在数据上运行其他工具，如果文件存储在数据库中，则无法使用这些工具。
答案 5 :(得分：0)
我会将它们存储在数据库中：
由于您谈论的是少量图片，因此易于使用/管理应优先考虑相关问题中争论的性能问题。
答案 6 :(得分：0)
我认为存在将其存储在数据库中的可管理性优势;它们可以与其他数据一致地备份和恢复 - 你不会忘记删除过时的数据（好吧，你可能会，但它有点不太可能），如果你将数据库迁移到另一台机器，那么图像就是它
答案 7 :(得分：0)
数据库针对延迟，事务等进行了优化。
图像存储针对读取延迟，存储成本等进行了优化。
blob存储非常适合存储数百万个图像。我在SeaweedFS上工作。它基于Facebook用于存储用户照片的设计。