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

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


当前回答

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

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

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

其他回答

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

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

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

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

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

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

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

摘自MSDN文章:

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

在我曾经工作过的一家公司,我们在Oracle 8i(当时是9i)数据库中存储了1.55亿张图像。7.5 tb的价值。

我们实现了一个文档成像系统,它将所有图像存储在SQL2005 blob字段中。目前有几百GB,我们看到了出色的响应时间和很少或没有性能下降。此外,fr法规遵从性,我们有一个中间件层,将新发布的文档归档到光学点唱机系统,该系统将它们公开为标准NTFS文件系统。

我们对结果非常满意,特别是在以下方面:

易于复制和备份 能够轻松实现文档版本控制系统