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