Database 在DB中存储图像-是还是不是？

因此，我使用的应用程序在数据库中大量存储图像。你对此有何看法？我更喜欢将位置存储在文件系统中，而不是直接存储在数据库中

---

你认为有什么优点/缺点

我负责管理许多TB图像的一些应用程序。我们发现在数据库中存储文件路径是最好的

有几个问题：

• 数据库存储通常比文件系统存储更昂贵
• 您可以使用标准的现成产品超级加速文件系统访问
  • 例如，许多web服务器使用操作系统的sendfile（）系统调用将文件直接从文件系统异步发送到网络接口。存储在数据库中的图像不会从这种优化中受益
• web服务器等不需要特殊编码或处理来访问文件系统中的图像
• 在图像和元数据之间的事务完整性非常重要的情况下，数据库胜出。
  • 管理数据库元数据和文件系统数据之间的完整性更为复杂
  • 很难（在web应用程序的上下文中）保证数据已刷新到文件系统上的磁盘

---

通常，我非常反对将基础设施（数据库）中最昂贵、最难扩展的部分，并将所有负载都放在其中。另一方面，它大大简化了备份策略，特别是当您有多个web服务器并且需要以某种方式保持数据同步时

---

与大多数其他事项一样，它取决于预期的大小和预算。

请支持有关文件路径的建议。我曾参与过几个需要管理大型ish资产集合的项目，任何直接在DB中存储东西的尝试都会带来长期的痛苦和挫折

关于将它们存储在数据库中，我能想到的唯一真正的“专业”是易于使用单个图像资产的潜力。如果没有可使用的文件路径，并且所有图像都直接从数据库中流出，那么用户就不会发现他们不应该访问的文件

---

不过，通过中间脚本从无法访问的web文件存储中提取数据似乎可以更好地解决这个问题。因此，DB存储并非真正必要。

如果这是基于web的应用程序，那么将图像存储在第三方存储交付网络（如Amazon的S3或Nirvanix平台）上可能会有好处。

根据我的经验，有时最简单的解决方案是根据主键为图像命名。因此很容易找到属于特定记录的图像，反之亦然。但与此同时，您没有在数据库中存储任何有关图像的信息。

数据库中的文件路径肯定是可行的-我从拥有TB图像的客户那里听到了一个又一个故事，试图在数据库中存储大量图像成了一场噩梦-单是性能上的损失就太大了很多。

在我曾经工作过的一家公司，我们在Oracle 8i（然后是9i）数据库中存储了1.55亿张图像。价值7.5TB。

不经常编辑的小型静态图像（不超过两个MEG）应存储在数据库中。这种方法有几个好处，包括更易于移植（图像随数据库传输）、更易于备份/恢复（图像随数据库备份）和更好的可伸缩性（一个包含数千个小缩略图文件的文件系统文件夹对我来说简直是可伸缩性的噩梦）

---

从数据库提供图像很容易，只需实现一个http处理程序，将DB服务器返回的字节数组作为二进制流提供服务。

这可能有点遥不可及，但如果您正在使用（或计划使用）SQL server 2008，我建议您查看新的数据类型

FileStream解决了在数据库中存储文件的大部分问题：

这些blob实际上作为文件存储在一个文件夹中

可以使用数据库连接或通过文件系统访问blob

备份是集成的

迁移“只起作用”

然而，SQL的“透明数据加密”并不加密FileStream对象，所以如果考虑到这一点，您最好将它们存储为varbinary

从MSDN文章中：

Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流式访问。
FILESTREAM使用NT系统缓存缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的任何影响。未使用SQL Server缓冲池；因此，该内存可用于查询处理

---

人们普遍认为，除非你是一家数据库供应商，试图证明你的数据库能够做到这一点（比如说，微软吹嘘Terraserver在SQL Server中存储了数以百万计的图像），否则这不是一个好主意。当替代方法——将图像存储在文件服务器和数据库中的路径上变得如此简单时，为什么还要麻烦呢？Blob fields有点像SUV的越野功能-大多数人不使用它们，那些通常会遇到麻烦的人，还有一些人使用它们，但这只是为了好玩。

有一件事我还没有看到有人提到，但绝对值得注意的是，在大多数文件系统中存储大量图像也存在相关问题。例如，如果您采用上述方法，并以主键命名每个图像文件，那么在大多数文件系统中，如果您试图在访问大量图像（例如几十万或数百万）后将所有图像放在一个大目录中，则会遇到问题

这一问题一旦得到普遍解决