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

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


当前回答

不经常编辑的小静态图像(不超过几兆)应该存储在数据库中。这种方法有几个好处,包括更容易移植(图像与数据库一起传输),更容易备份/恢复(图像与数据库一起备份)和更好的可伸缩性(一个包含数千个小缩略图文件的文件系统文件夹对我来说听起来像是可伸缩性的噩梦)。

从数据库提供图像很简单,只需实现一个http处理程序,将从DB服务器返回的字节数组作为二进制流提供服务。

其他回答

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

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

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

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

摘自MSDN文章:

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

你的网络服务器(我假设你正在使用)是用来处理图像的,而数据库不是。因此,我会大力投反对票。

在数据库中只存储路径(可能还有文件信息)。

在数据库中存储图像仍然意味着图像数据最终位于文件系统中的某个位置,但被遮蔽,因此您不能直接访问它。

+压力:

数据库的完整性 它易于管理,因为您不必担心在添加或删除映像时保持文件系统同步

-维斯:

性能损失——数据库查找通常比文件系统查找慢 您不能直接编辑图像(裁剪,调整大小)

这两种方法都是常见的和实践的。看看优点和缺点。无论哪种方式,你都必须考虑如何克服缺点。在数据库中存储通常意味着调整数据库参数并实现某种缓存。使用文件系统要求您找到某种保持文件系统+数据库同步的方法。

数据数据库

文件的文件系统

这里的诀窍是不要成为一个狂热分子。

这里需要注意的一点是,在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?

No.

事实上,许多数据库都胜过许多文件系统,即使我们只讨论原始速度。

正确的做法是为您的精确场景做出正确的决定,要做到这一点,您需要一些数字和一些用例估计。