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

文件存储中的图像是最好的选择，可以通过将元数据存储在数据库中来补充。从Web服务器的角度来看，快速提供服务的方法是直接指向它。如果它在数据库中-比如Sharepoint-您需要使用ADO.Net来提取、流式传输等操作。

虽然Documentum臃肿而复杂，但它的做法是正确的，因为文件在共享上可用，您可以确定如何存储它们-服务器上的磁盘、SAN、NAS等。Documentum策略是通过根据其主键在DB中对文件夹和文件名进行编码，将文件存储为树形结构。DB成为了知道哪些文件是什么以及强制执行安全性的资源。对于高容量系统，这种方法是一个不错的选择。

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

如果您计划创建一个公共面向网站，那么您不应该选择其中任何一种选项。您应该使用内容分发网络（CDN）。在通过互联网传递大量静态内容时，CDN具有价格、可扩展性和速度优势。

我会选择文件系统方法。正如其他人所指出的那样，大多数Web服务器都是从文件路径发送图像的。如果您不必从数据库中编写或流式传输BLOB字段，则性能将更高。为图像设置文件系统存储使得在内容不变或者想要限制数据库负载时更容易设置静态页面。

不行，因为页面分裂的原因。你基本上是在定义可以是1KB - n MB的行，所以你的数据库将会有很多空白空间，这对性能不利。

在我目前的应用程序中，我两者都做。当用户确定要附加到记录的图像时，我使用ImageMagick将其调整大小为适合屏幕显示的适当尺寸（我的应用程序大约是300x300），并将其存储在数据库中以便于访问，但也将用户的原始文件复制到网络共享中，以便需要更高分辨率的应用程序使用（例如打印）。

还有其他几个因素：Navision只能显示BMP格式的图像，所以在调整大小时，我还会转换为BMP格式进行存储，并且数据库会被复制到远程站点，在那里显示图像非常有用。打印只在总部进行，因此我不需要复制原始文件。

在我的小应用程序中，我至少有一百万个文件，重量达到了大约200GB。所有文件都坐落在通过iscsi连接挂载在Linux服务器上的XFS文件系统中。路径存储在数据库中，请使用某种智能命名约定来为您的文件路径和文件名命名。
在我看来，要使用文件系统完成其预期工作-存储文件。通常情况下，数据库在存储二进制数据方面并不比标准文件系统提供任何优势。