所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
这可能有点不切实际,但如果你正在使用(或计划使用)SQL Server 2008,我建议你看看新的FileStream数据类型。
FileStream解决了在DB中存储文件的大部分问题:
blob实际上以文件的形式存储在文件夹中。 可以使用数据库连接或通过文件系统访问blob。 备份是集成的。 迁移“就是管用”。
然而,SQL的“透明数据加密”不加密FileStream对象,因此如果考虑到这一点,最好将它们存储为varbinary。
摘自MSDN文章:
Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问。 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;因此,该内存可用于查询处理。
其他回答
我将采用文件系统方法。正如其他一些人所指出的,大多数web服务器被构建为从文件路径发送图像。如果您不需要从数据库中写入或输出BLOB字段,那么您将获得更高的性能。当内容不变或希望限制数据库负载时,将图像存储在文件系统中可以更容易地设置静态页面。
我是一个企业文档管理系统的首席开发人员,一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法是出于本页提到的许多原因,另外还有一个原因:存档。
我们的许多客户必须遵守行业特定的存档规则,例如存储到光盘或非专有格式的存储。此外,您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中,即使使用SQL Server 2008的文件流数据类型,你的存档选项也会变得非常狭窄。
根据我的经验,我必须管理两种情况:图像存储在数据库和图像文件系统的路径存储在db。
第一个解决方案,数据库中的图像,有点“干净”,因为你的数据访问层将只需要处理数据库对象;但这只在你必须处理小数字的时候有用。
显然,当您处理二进制大对象时,数据库访问性能正在下降,数据库维度将增长很多,再次导致性能损失…通常数据库空间比文件系统空间要昂贵得多。
另一方面,在文件系统中存储大型二进制对象将导致您的备份计划必须同时考虑数据库和文件系统,这对于某些系统可能是一个问题。
使用文件系统的另一个原因是当你必须与第三方访问共享你的图像数据(或声音、视频等)时:在这一天,我正在开发一个web应用程序,它使用的图像必须从“外部”我的网络农场访问,以这样一种方式访问数据库来检索二进制数据是根本不可能的。所以有时候也会有设计上的考虑促使你做出选择。
在做出这种选择时,还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时,这些必要条件通常可以以更简单的方式解决。
您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。
如果你有一个小的,单用户的消费应用程序,那么我会说DB。我有一个DVD管理应用程序,使用文件系统(在程序文件中),它是一个PIA备份。我希望他们每次都能把它们存储在数据库中,让我选择保存文件的位置。
对于一个更大的商业应用,我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上,以一种编码格式(以处理大量文件的FS问题),基于县指定的仪器编号。这在另一个方面是有用的,因为图像可以在DB记录之前存在(由于他们的工作流程)。
和大多数事情一样:“这取决于你在做什么”
在我的小应用程序中,我至少有100万个文件,最近一次统计大约200GB。所有文件都位于通过iscsi挂载在linux服务器上的XFS文件系统中。路径存储在数据库中。对文件路径和文件名使用某种智能命名约定。
恕我直言,使用文件系统是为了做什么-存储文件。在存储二进制数据方面,数据库通常不比标准文件系统提供任何优势。