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

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


当前回答

根据我的经验,有时最简单的解决方案是根据主键来命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,你并没有在数据库中存储图像的任何信息。

其他回答

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

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

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

我个人会将大数据存储在数据库之外。

优点:存储所有东西在一个请,容易访问数据文件,容易备份 缺点:降低数据库性能,很多页面分割,可能导致数据库损坏

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

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

No.

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

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

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

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

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

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

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