所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
SQL Server 2008提供了一个两者兼备的解决方案:文件流数据类型。
像管理普通表一样管理它,并具有文件系统的性能。
其他回答
通过网络将二进制数据从数据库中取出会导致巨大的延迟问题,并且伸缩性不好。
将路径存储在数据库中,让你的web服务器承担负载——这就是它的设计目的!
如果您没有使用SQL Server 2008,并且有充分的理由将特定的映像文件放在数据库中,那么您可以采用“两者兼备”的方法,将文件系统用作临时缓存,并将数据库用作主存储库。
例如,您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上,并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。
我们实现了一个文档成像系统,它将所有图像存储在SQL2005 blob字段中。目前有几百GB,我们看到了出色的响应时间和很少或没有性能下降。此外,fr法规遵从性,我们有一个中间件层,将新发布的文档归档到光学点唱机系统,该系统将它们公开为标准NTFS文件系统。
我们对结果非常满意,特别是在以下方面:
易于复制和备份 能够轻松实现文档版本控制系统
DB中的文件路径绝对是可行的方法——我从拥有TB图像的客户那里听到了一个又一个故事,试图在DB中存储大量图像都是一场噩梦——单是性能损失就太大了。
我将使用文件系统方法,主要是因为它具有更好的灵活性。考虑一下,如果图像的数量变得很大,一个数据库可能无法处理它。对于文件系统,您可以简单地添加更多的文件服务器,假设您正在使用NFS或kind。
文件系统方法的另一个优点是能够做一些奇特的事情,例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断,则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。