所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
根据我的经验,有时最简单的解决方案是根据主键来命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,你并没有在数据库中存储图像的任何信息。
其他回答
我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的,在工作流结束时被删除。如果有任何形式的长期存储,我们肯定会选择存储文件路径。
还应该注意的是,我们在内部使用客户端/服务器应用程序,因此不需要担心web界面。
文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。
大海捞针:高效存储数十亿张照片
这可能有点不切实际,但如果你正在使用(或计划使用)SQL Server 2008,我建议你看看新的FileStream数据类型。
FileStream解决了在DB中存储文件的大部分问题:
blob实际上以文件的形式存储在文件夹中。 可以使用数据库连接或通过文件系统访问blob。 备份是集成的。 迁移“就是管用”。
然而,SQL的“透明数据加密”不加密FileStream对象,因此如果考虑到这一点,最好将它们存储为varbinary。
摘自MSDN文章:
Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问。 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;因此,该内存可用于查询处理。
如果这是基于web的应用程序,那么将图像存储在第三方存储交付网络(如Amazon的S3或Nirvanix平台)上可能会有优势。
我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中,并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:
通过更新全局配置,将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具,如imagemagick。 在web应用程序中,您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。