所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。

你认为优点和缺点是什么?


当前回答

I have worked with many digital storage systems and they all store digital objects on the file system. They tend to use a branch approach, so there will be an archive tree on the file system, often starting with year of entry e.g. 2009, subdirectory will be month e.g. 8 for August, next directory will be day e.g. 11 and sometimes they will use hour as well, the file will then be named with the records persistent ID. Using BLOBS has its advantages and I have heard of it being used often in the IT parts of the chemical industry for storing thousands or millions of photographs and diagrams. It can provide more granular security, a single method of backup, potentially better data integrity and improved inter media searching, Oracle has many features for this within the package they used to call Intermedia (I think it is called something else now). The file system can also have granular security provided through a system such as XACML or another XML type security object. See D Space of Fedora Object Store for examples.

其他回答

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

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

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

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

这可能有点不切实际,但如果你正在使用(或计划使用)SQL Server 2008,我建议你看看新的FileStream数据类型。

FileStream解决了在DB中存储文件的大部分问题:

blob实际上以文件的形式存储在文件夹中。 可以使用数据库连接或通过文件系统访问blob。 备份是集成的。 迁移“就是管用”。

然而,SQL的“透明数据加密”不加密FileStream对象,因此如果考虑到这一点,最好将它们存储为varbinary。

摘自MSDN文章:

Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问。 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;因此,该内存可用于查询处理。

尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储,那么最终编写的代码会更少,结果也会更好。

在数据库中只存储映像的文件路径的问题是,不能再强制数据库的完整性。

如果文件路径所指向的实际映像变得不可用,则数据库会不知不觉地出现完整性错误。

考虑到图像是被寻找的实际数据,并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失),而不必与某种文件系统(如果文件系统是独立访问的,图像可能会突然“消失”),我倾向于将它们直接存储为BLOB或类似的文件系统。