文件存储上的图像是最好的选择，并将元数据存储在数据库中作为补充。从web服务器的角度来看，提供东西的最快方法是直接指向它。如果它在数据库中——比如Sharepoint——你就有ADO的开销。用网把它拉出来，流出来，等等。

Documentum -虽然臃肿和复杂-有它的权利，文件是在共享和可供您决定如何存储它们-磁盘上的服务器，SAN, NAS，无论什么。Documentum的策略是根据数据库中的主键对文件夹和文件名进行编码，从而将文件存储为树状结构。DB成为了解什么文件是什么文件和加强安全性的资源。对于大容量系统，这种方法是一种很好的方法。

在处理元数据时也要考虑这一点:如果您需要更新元数据语料库的属性，DB是您的朋友，因为您可以使用SQL快速执行更新。使用其他标记系统，您手头没有简单的数据操作工具

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

像大多数其他事情一样，这取决于预期的规模和预算。

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

我将采用文件系统方法。不需要创建或维护带有映像的DB，从长远来看，这将为您节省一些主要的麻烦。

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

优点:

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

缺点:

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

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

我更喜欢将图像路径存储在DB中，并将图像存储在文件系统中(在服务器之间使用rsync以保持所有内容的合理最新)。

然而，我所做的一些内容管理系统的工作需要在CMS中使用图像，原因有几个——可见性控制(因此资产被保留到新闻稿发布之前)、版本控制、重新格式化(一些CMS将动态调整缩略图的大小)以及将图像链接到所见即所得页面的易用性。

因此，我的经验法则是始终将应用程序的内容保存在文件系统中，除非它是CMS驱动的。