在 Web 应用程序的上下文中，我的前老板总是说在数据库中放置对图像的引用，而不是图像本身。我倾向于同意在数据库中存储 url 与图像本身是一个好主意，但在我现在工作的地方，我们在数据库中存储大量图像。
我能想到的唯一原因可能是它更安全？您不希望有人直接链接到某个网址吗？但如果是这种情况，您始终可以让网站/服务器处理图像，就像 asp.net 中的处理程序一样，以便用户需要进行身份验证才能查看图像。我还认为从数据库中提取图像会损害性能。还有其他原因可以解释为什么将图像存储在数据库中是个好主意/不太好主意吗？
精确重复： 用户图像：数据库还是文件系统存储？ https://stackoverflow.com/questions/585224/user-images-database-vs-filesystem-storage
精确重复： 在数据库中存储图像：是还是不是？ https://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay
精确重复： 我应该将图像存储在数据库还是文件夹中？ https://stackoverflow.com/questions/713243/should-i-store-my-images-in-the-database-or-folders
精确重复： 您会将二进制数据存储在数据库或文件夹中吗？ https://stackoverflow.com/questions/662488/would-you-store-binary-data-in-database-or-in-file-system
精确重复： 将图片存储为文件或网络应用程序的数据库？ https://stackoverflow.com/questions/561447/store-pictures-as-files-or-in-the-database-for-a-web-app
精确重复： 存储少量图像：blob 还是 fs？ https://stackoverflow.com/questions/325126/storing-a-small-number-of-images-blob-or-fs
精确重复： 将图像存储在文件系统或数据库中？ https://stackoverflow.com/questions/766048/store-image-in-database-or-in-a-system-file
将图像放入数据库的优点。
交易。保存 blob 时，您可以像任何其他数据库数据一样提交它。这意味着您可以提交 blob 以及任何关联的元数据，并确保两者同步。如果磁盘空间不足？没有提交。文件未完全上传？没有提交。愚蠢的应用程序错误？没有提交。如果保持图像及其关联的元数据彼此一致对于您的应用程序很重要，那么数据库可以提供的事务可能会是一个福音。
一套系统即可管理。需要备份元数据和 blob？备份数据库。需要复制它们吗？复制数据库。需要从部分系统故障中恢复吗？重新加载数据库并前滚日志。 DB 为一般数据带来的所有优势（卷映射、存储控制、备份、复制、恢复等）都适用于您的 blob。一致性更高，管理更轻松。
安全。数据库具有可以利用的非常细粒度的安全功能。架构、用户角色，甚至“只读视图”之类的东西都可以安全地访问数据子集。所有这些功能也适用于保存 blob 的表。
集中管理。与 #2 相关，但基本上 DBA（就好像他们没有足够的权力一样）需要管理一件事：数据库。现代数据库（尤其是较大的数据库）非常适合跨多台机器的大型安装。单一管理来源简化了程序，简化了知识转移。
大多数现代数据库都能很好地处理 blob。借助数据层中对 Blob 的一流支持，您可以轻松地将 Blob 从数据库流式传输到客户端。虽然您可以执行一些操作来一次性“吸入”整个 blob，但如果您不需要该功能，则不要使用它。研究数据库的 SQL 接口并利用其功能。没有理由将它们视为“大字符串”，将它们整体处理并将您的斑点变成大的、吞噬内存、破坏缓存的炸弹。
就像您可以为图像设置专用文件服务器一样，您可以在数据库中设置专用 Blob 服务器。为它们提供专用磁盘卷、专用模式、专用缓存等。数据库中的所有数据都不相同，或者行为相同，没有理由将其配置为完全相同。好的数据库具有精细的控制水平。
从数据库提供 blob 的主要问题是确保 HTTP 层实际上利用所有 HTTP 协议来执行服务。
许多幼稚的实现只是简单地抓取 blob，然后将它们批量转储到套接字中。但 HTTP 有几个非常适合流图像等的重要功能。特别是缓存标头、ETag 和分块传输，以允许客户端请求 Blob 的“片段”。
确保您的 HTTP 服务正确处理所有这些请求，并且您的数据库可以成为非常好的 Web 公民。通过将文件缓存在文件系统中以供 HTTP 服务器提供服务，您可以“免费”获得其中一些优势（因为好的服务器无论如何都会对“静态”资源执行此操作），但请确保如果您这样做，您尊重图像的修改日期等内容。
例如，某人请求 spaceshuttle.jpg，这是 2009 年 1 月 1 日创建的图像。该图像最终会在请求日期（例如 2009 年 2 月 1 日）缓存在文件系统上。随后，该图像会从缓存中清除（先进先出策略） ，或其他什么），后来有人在 2009 年 3 月 1 日再次请求。好吧，现在它的“创建日期”是 2009 年 3 月 1 日，尽管它的创建日期实际上是 1 月 1 日。因此，您可以看到，特别是如果您的缓存周转频繁，客户端可能正在使用 If-修改后的标头可能会获取比实际需要更多的数据，因为服务器认为资源已更改，但实际上并未更改。
如果您使缓存创建日期与实际创建日期保持同步，那么这可能不是什么问题。
但重点是，为了成为“优秀的网络公民”，需要仔细思考整个问题，并为您和您的客户节省一些潜在的带宽等。
我刚刚为一个从数据库提供视频的 Java 项目经历了所有这些，一切都很顺利。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
