所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
SQL Server 2008提供了一个两者兼备的解决方案:文件流数据类型。
像管理普通表一样管理它,并具有文件系统的性能。
其他回答
我会选择两种解决方案,我的意思是……我将开发一个小组件(EJB),它将映像存储在DB中,并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时,这个DB才会更新。然后,我还将该路径存储在业务DB中。
从应用程序的角度来看,我将始终使用文件系统(从业务DB检索路径),通过这种方式,我们将修复备份问题,并避免可能的性能问题。
唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜,拜托!
没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统,甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?
如果你的文件系统中有你的图像,当你写一个新版本甚至删除文件时,有人正在读取文件-会发生什么?
我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。
你的网络服务器(我假设你正在使用)是用来处理图像的,而数据库不是。因此,我会大力投反对票。
在数据库中只存储路径(可能还有文件信息)。
我曾经开发过一个图像处理应用程序。我们将上传的图像存储在类似于/images/[今天的日期]/[id号]的目录中。但是我们还从图像中提取了元数据(exif数据),并将其连同时间戳等一起存储在数据库中。
这里的诀窍是不要成为一个狂热分子。
这里需要注意的一点是,在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?
No.
事实上,许多数据库都胜过许多文件系统,即使我们只讨论原始速度。
正确的做法是为您的精确场景做出正确的决定,要做到这一点,您需要一些数字和一些用例估计。