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

这里有几个问题:

database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem

正如其他人所说，SQL 2008提供了一个Filestream类型，允许您将文件名或标识符作为指针存储在db中，并自动将图像存储在您的文件系统中，这是一个很好的场景。

如果您使用的是较旧的数据库，那么我会说，如果您将其存储为blob数据，那么您将无法通过搜索特性的方式从数据库中获得任何内容，因此最好将地址存储在文件系统上，并以这种方式存储图像。

这样还可以节省文件系统上的空间，因为您只会在文件系统上节省确切数量的空间，甚至是压缩的空间。

此外，您可以决定保存一些结构或元素，允许您在文件系统中浏览原始图像而不需要任何db访问，或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置，但保留结构，当尝试增加存储空间时，也不需要尝试将图像从db中取出。

也许，它也会允许你抛出一些缓存元素，基于常用的图像url到你的web引擎/程序，所以你也把自己保存在那里。

DB中的文件路径绝对是可行的方法——我从拥有TB图像的客户那里听到了一个又一个故事，试图在DB中存储大量图像都是一场噩梦——单是性能损失就太大了。

在我的小应用程序中，我至少有100万个文件，最近一次统计大约200GB。所有文件都位于通过iscsi挂载在linux服务器上的XFS文件系统中。路径存储在数据库中。对文件路径和文件名使用某种智能命名约定。

恕我直言，使用文件系统是为了做什么-存储文件。在存储二进制数据方面，数据库通常不比标准文件系统提供任何优势。

在必须保证引用完整性和ACID遵从性的地方，需要在数据库中存储图像。

你不能保证图像和存储在数据库中的关于该图像的元数据引用同一个文件。换句话说，不可能保证文件系统上的文件只与元数据在同一时间和同一事务中被修改。

我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的，在工作流结束时被删除。如果有任何形式的长期存储，我们肯定会选择存储文件路径。

还应该注意的是，我们在内部使用客户端/服务器应用程序，因此不需要担心web界面。