您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。

如果你有一个小的，单用户的消费应用程序，那么我会说DB。我有一个DVD管理应用程序，使用文件系统(在程序文件中)，它是一个PIA备份。我希望他们每次都能把它们存储在数据库中，让我选择保存文件的位置。

对于一个更大的商业应用，我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上，以一种编码格式(以处理大量文件的FS问题)，基于县指定的仪器编号。这在另一个方面是有用的，因为图像可以在DB记录之前存在(由于他们的工作流程)。

和大多数事情一样:“这取决于你在做什么”

文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。

大海捞针:高效存储数十亿张照片

我曾经开发过一个图像处理应用程序。我们将上传的图像存储在类似于/images/[今天的日期]/[id号]的目录中。但是我们还从图像中提取了元数据(exif数据)，并将其连同时间戳等一起存储在数据库中。

我最近创建了一个PHP/MySQL应用程序，用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。

优点:

上传的文件复制到备份服务器连同其他一切，不需要单独的备份策略(安心)。 设置web服务器稍微简单一些，因为我不需要有一个上传/文件夹，并告诉我所有的应用程序它在哪里。 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件

缺点:

mysqldump现在需要很长时间，因为其中一个表中有500MB的文件数据。 总的来说，与文件系统相比，内存/cpu效率不是很高

我认为我的实现是成功的，它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说，性能还不错。

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

我负责一些管理许多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