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

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


当前回答

正如其他人所说,SQL 2008提供了一个Filestream类型,允许您将文件名或标识符作为指针存储在db中,并自动将图像存储在您的文件系统中,这是一个很好的场景。

如果您使用的是较旧的数据库,那么我会说,如果您将其存储为blob数据,那么您将无法通过搜索特性的方式从数据库中获得任何内容,因此最好将地址存储在文件系统上,并以这种方式存储图像。

这样还可以节省文件系统上的空间,因为您只会在文件系统上节省确切数量的空间,甚至是压缩的空间。

此外,您可以决定保存一些结构或元素,允许您在文件系统中浏览原始图像而不需要任何db访问,或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置,但保留结构,当尝试增加存储空间时,也不需要尝试将图像从db中取出。

也许,它也会允许你抛出一些缓存元素,基于常用的图像url到你的web引擎/程序,所以你也把自己保存在那里。

其他回答

如果您使用Teradata,那么Teradata Developer Exchange有一篇关于加载和检索lobs和blobs的详细文章。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

我会选择两种解决方案,我的意思是……我将开发一个小组件(EJB),它将映像存储在DB中,并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时,这个DB才会更新。然后,我还将该路径存储在业务DB中。

从应用程序的角度来看,我将始终使用文件系统(从业务DB检索路径),通过这种方式,我们将修复备份问题,并避免可能的性能问题。

唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜,拜托!

我将采用文件系统方法。不需要创建或维护带有映像的DB,从长远来看,这将为您节省一些主要的麻烦。

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

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

数据数据库

文件的文件系统