所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
将图像存储在文件系统中的另一个好处是,您不需要做任何特殊的事情来让客户端缓存它们……
...当然,除非图像不能通过文档根访问(例如身份验证障碍),在这种情况下,你需要检查你的代码正在发送的缓存控制头。
其他回答
我是一个企业文档管理系统的首席开发人员,一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法是出于本页提到的许多原因,另外还有一个原因:存档。
我们的许多客户必须遵守行业特定的存档规则,例如存储到光盘或非专有格式的存储。此外,您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中,即使使用SQL Server 2008的文件流数据类型,你的存档选项也会变得非常狭窄。
通过网络将二进制数据从数据库中取出会导致巨大的延迟问题,并且伸缩性不好。
将路径存储在数据库中,让你的web服务器承担负载——这就是它的设计目的!
对于大量的小图像,数据库可能更好。
我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时,由于文件系统的块大小,它们每个都消耗了8kb。空间增加了400% !
有关块大小的更多信息,请参阅这篇文章: iphone文件系统的块大小是多少?
我们实现了一个文档成像系统,它将所有图像存储在SQL2005 blob字段中。目前有几百GB,我们看到了出色的响应时间和很少或没有性能下降。此外,fr法规遵从性,我们有一个中间件层,将新发布的文档归档到光学点唱机系统,该系统将它们公开为标准NTFS文件系统。
我们对结果非常满意,特别是在以下方面:
易于复制和备份 能够轻松实现文档版本控制系统
正如其他人所说,SQL 2008提供了一个Filestream类型,允许您将文件名或标识符作为指针存储在db中,并自动将图像存储在您的文件系统中,这是一个很好的场景。
如果您使用的是较旧的数据库,那么我会说,如果您将其存储为blob数据,那么您将无法通过搜索特性的方式从数据库中获得任何内容,因此最好将地址存储在文件系统上,并以这种方式存储图像。
这样还可以节省文件系统上的空间,因为您只会在文件系统上节省确切数量的空间,甚至是压缩的空间。
此外,您可以决定保存一些结构或元素,允许您在文件系统中浏览原始图像而不需要任何db访问,或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置,但保留结构,当尝试增加存储空间时,也不需要尝试将图像从db中取出。
也许,它也会允许你抛出一些缓存元素,基于常用的图像url到你的web引擎/程序,所以你也把自己保存在那里。