所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
根据我的经验,有时最简单的解决方案是根据主键来命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,你并没有在数据库中存储图像的任何信息。
其他回答
有一件事我还没有看到任何人提到,但绝对值得注意的是,在大多数文件系统中也存在与存储大量图像相关的问题。例如,如果您采用上面提到的方法,以主键命名每个图像文件,在大多数文件系统上,如果您试图将所有图像放在一个大目录中,一旦您达到了非常大的图像数量(例如数十万或数百万),您将遇到问题。
常见的解决方案是将它们散列到平衡的子目录树中。
通常,我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库),并将所有负载都放在其中。另一方面:它极大地简化了备份策略,特别是当你有多个web服务器,需要以某种方式保持数据同步时。
像大多数其他事情一样,这取决于预期的规模和预算。
这可能有点不切实际,但如果你正在使用(或计划使用)SQL Server 2008,我建议你看看新的FileStream数据类型。
FileStream解决了在DB中存储文件的大部分问题:
blob实际上以文件的形式存储在文件夹中。 可以使用数据库连接或通过文件系统访问blob。 备份是集成的。 迁移“就是管用”。
然而,SQL的“透明数据加密”不加密FileStream对象,因此如果考虑到这一点,最好将它们存储为varbinary。
摘自MSDN文章:
Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问。 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;因此,该内存可用于查询处理。
根据我的经验,有时最简单的解决方案是根据主键来命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,你并没有在数据库中存储图像的任何信息。
我是一个企业文档管理系统的首席开发人员,一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法是出于本页提到的许多原因,另外还有一个原因:存档。
我们的许多客户必须遵守行业特定的存档规则,例如存储到光盘或非专有格式的存储。此外,您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中,即使使用SQL Server 2008的文件流数据类型,你的存档选项也会变得非常狭窄。