在必须保证引用完整性和acid遵从性的地方，需要在数据库中存储图像。
您不能事务性地保证存储在数据库中的图像和关于该图像的元数据引用同一个文件。换句话说，不可能保证文件系统上的文件只在同一时间和同一事务中与元数据发生更改。

通常情况下，我反对将基础设施（数据库）中最昂贵、最难扩展的部分放入其中，并将所有负载都放入其中。另一方面：它大大简化了备份策略，特别是在

数据库中的文件路径绝对是一个不错的选择—我从拥有tb图像的客户那里听到了一个又一个故事，他们说在数据库中存储大量图像会成为一场噩梦—单是性能方面的影响就太大了。

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

没有人提到的是，db保证原子操作、事务完整性和处理并发性。即使引用完整性在文件系统中也是不存在的—那么您如何知道您的文件名仍然是正确的呢？
如果您在文件系统中有图像，并且有人在您编写新版本甚至删除文件时读取该文件-会发生什么情况？
我们使用blob是因为它们更易于管理（备份、复制、传输）。他们为我们工作得很好。

不经常编辑的小静态图像（不超过两个MEG）应存储在数据库中。这种方法有几个好处，包括更容易移植（图像通过数据库传输）、更容易备份/恢复（图像通过数据库备份）和更好的可伸缩性（一个包含数千个小缩略图文件的文件系统文件夹对我来说就像是可伸缩性的噩梦）。
从数据库提供图像很容易，只需实现一个http处理程序，将db服务器返回的字节数组作为二进制流提供服务。

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

这可能有点遥不可及，但如果您正在使用（或计划使用）SQLServer2008，我建议您看看新的filestream数据类型。
filestream解决了在数据库中存储文件的大部分问题：
这些blob实际上作为文件存储在一个文件夹中。
可以使用数据库连接或通过文件系统访问blob。
备份是集成的。
迁移“只是工作”。
然而，sql的“透明数据加密”并不加密filestream对象，因此如果考虑到这一点，您最好将它们存储为varbinary。
来自msdn文章：
transact-sql语句可以插入、更新、查询、搜索和备份filestream数据。win32文件系统接口提供对数据的流式访问。
filestream使用nt系统缓存来缓存文件数据。这有助于减少filestream数据对数据库引擎性能的任何影响。未使用sql server缓冲池；因此，该内存可用于查询处理。

正如其他人所说，SQL2008附带了一个文件流类型，它允许您将文件名或标识符作为指针存储在数据库中，并自动将图像存储在文件系统中，这是一个很好的方案。
如果您使用的是一个较旧的数据库，那么我会说，如果您将其存储为blob数据，那么在搜索功能时，您实际上不会从数据库中获得任何信息，因此最好将地址存储在文件系统中，并以这种方式存储映像。
这样还可以节省文件系统上的空间，因为您只需要在文件系统上节省确切的空间量，甚至压缩的空间。
此外，您还可以决定使用一些结构或元素进行保存，这些结构或元素允许您浏览文件系统中的原始图像，而无需任何db命中，或者将文件批量传输到另一个系统、硬盘驱动器、s3或其他场景—更新程序中的位置，但保留结构，再次没有太多的打击，试图把你的数据库图像时，试图增加存储。
可能，它还允许您将一些缓存元素（基于常见的命中图像url）放入您的web引擎/程序中，这样您就可以在那里保存自己了。

这是一份关于这个主题的有趣的白皮书。
blob或not to blob：数据库或文件系统中的大型对象存储
答案是“视情况而定”，当然这取决于数据库服务器及其blob存储方法。它还取决于存储在blob中的数据类型，以及如何访问这些数据。
使用数据库作为存储机制，可以有效地存储和传递较小的文件。较大的文件最好使用文件系统存储，尤其是经常修改/更新的文件(blob碎片将成为性能方面的一个问题。）
还有一点要记住。支持使用数据库存储blob的原因之一是acid遵从性。然而，测试人员在白皮书中使用的方法（sql server的bulk logged选项）将sql server吞吐量提高了一倍，有效地将acid中的“d”改为“d”，因为blob数据没有与事务的初始写入一起记录。因此，如果对系统来说完全符合acid是一个重要的要求，那么在比较文件i/o和数据库blob i/o时，将数据库写入的sql server吞吐量数字减半。

在我曾经工作过的一家公司，我们在oracle8i（当时是9i）数据库中存储了1.55亿张图像。价值7.5tb。

文件存储。facebook的工程师们对此进行了精彩的讨论。其中一个好处是了解目录中文件的实际限制。
大海捞针：数十亿张照片的高效存储

这里的诀窍是不要成为狂热分子。
这里需要注意的一点是，pro文件系统阵营中没有人列出特定的文件系统。这是否意味着从fat16到zfs的一切都轻而易举地击败了所有数据库？
不。
事实是，许多数据库胜过许多文件系统，即使我们只讨论原始速度。
正确的做法是为您的精确场景做出正确的决策，为此，您需要一些数字和一些用例估计。

和大多数问题一样，这并不像听起来那么简单。在某些情况下，将图像存储在数据库中是有意义的。
您存储的图像是动态变化的，比如说发票，您想得到一张2007年1月1日的发票吗？
政府希望你保持6年的历史
存储在数据库中的图像不需要不同的备份策略。存储在文件系统上的图像
如果图像在数据库中，则更容易控制对它们的访问。空闲管理员可以访问磁盘上的任何文件夹。它需要一个真正坚定的管理员去窥探数据库提取图像
另一方面，也有相关的问题
需要额外的代码来提取和流式处理图像
延迟可能比直接文件访问慢
数据库服务器负载较重

在数据库中只存储图像的文件路径的问题是，不能再强制数据库的完整性。
如果文件路径指向的实际图像变得不可用，则数据库会无意中出现完整性错误。
考虑到这些映像是正在寻找的实际数据，而且它们可以在一个集成的数据库中更容易地管理（映像不会突然消失），而不必与某种文件系统接口（如果文件系统是独立访问的，映像可能会突然“消失”），我会直接把它们存储为一个blob之类的东西。