在数据库中存储图像 - 是还是不是？

试图使用SQL模拟文件系统通常是一个不好的计划。如果你坚持使用文件系统进行外部存储，最终你会写出更少的代码，并获得同等或更好的结果。

从您的数据库中拉取大量的二进制数据将导致巨大的延迟问题并且不可扩展。
在数据库中存储路径，让您的Web服务器承担负载 - 这就是它被设计的用途！

文件系统，当然。这样你就可以使用所有操作系统功能来处理这些图像——备份、Web服务器，甚至只需使用像ImageMagick这样的工具批量更改脚本。如果你将它们存储在数据库中，那么你就需要编写自己的代码来解决这些问题。

有一件事情你需要记住，那就是你的数据集的大小。我相信Dillie-O是唯一一个接近要点的人。

如果你有一个小型的、单用户的消费者应用程序，那么我会建议使用数据库。我有一个DVD管理应用程序，它使用文件系统（在Program Files中），备份很麻烦。我希望每次他们都能将它们存储在数据库中，并让我选择保存该文件的位置。

对于一个更大的商业应用程序，我会开始改变我的思路。我曾经为一家开发县书记信息管理应用程序的公司工作过。我们会将图像以编码格式存储在磁盘上[以处理大量文件的FS问题]，基于县分配的仪器编号。这在另一个方面也很有用，因为图像可以存在于DB记录之前（由于他们的工作流程）。

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

将图像存储在文件系统中的另一个好处是，您无需采取任何特殊措施即可使客户端缓存它们...除非当然，该图像无法通过文档根目录访问（例如身份验证障碍），在这种情况下，您需要检查代码发送的缓存控制标头。

我更喜欢将图像路径存储在数据库中，而将图像存储在文件系统中（通过服务器之间的rsync保持一切相对最新）。

然而，我所做的一些内容管理系统需要将图像放在CMS中，原因有几个：可见性控制（因此资产被保留，直到新闻发布），版本控制，重新格式化（某些CMS将动态调整大小以用于缩略图）以及方便将图像链接到所见即所得页面。

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

我会选择文件系统方法。无需创建或维护图像数据库，这将在长期运行中为您节省大量麻烦。

我几乎从不将它们存储在数据库中。最好的方法通常是将图像存储在由中央配置变量控制的路径中，并根据数据库表和主键（如果可能）命名图像。这样做有以下优点：

• 通过更新全局配置，将图像移动到另一个分区或服务器。
• 通过搜索其主键来查找与图像匹配的记录。
• 您的图像可以被像ImageMagick这样的处理工具访问。
• 在Web应用程序中，您的图像可以直接由Web服务器处理（节省处理时间）。
• CMS工具和Web语言（如Coldfusion）可以本地处理上传。

如果您正在使用Teradata，那么Teradata开发者交流平台上有一篇关于加载和检索lobs和blobs的详细文章。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

我会采用两种解决方案，我的意思是...我将开发一个小组件（EJB），将图像存储在数据库中，并将其路径存储到服务器中。只有当我们有新的图像或原始图像更新时，才会更新此数据库。然后我还将在业务数据库中存储路径。

从应用程序的角度来看，我将始终使用文件系统（从业务数据库中检索路径），通过这种方式，我们将解决备份问题，并避免可能的性能问题。

唯一的弱点是我们将两次存储相同的图像...好处是内存很便宜，来吧！