所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
通常,我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库),并将所有负载都放在其中。另一方面:它极大地简化了备份策略,特别是当你有多个web服务器,需要以某种方式保持数据同步时。
像大多数其他事情一样,这取决于预期的规模和预算。
其他回答
有一件事我还没有看到任何人提到,但绝对值得注意的是,在大多数文件系统中也存在与存储大量图像相关的问题。例如,如果您采用上面提到的方法,以主键命名每个图像文件,在大多数文件系统上,如果您试图将所有图像放在一个大目录中,一旦您达到了非常大的图像数量(例如数十万或数百万),您将遇到问题。
常见的解决方案是将它们散列到平衡的子目录树中。
正如其他人所说,SQL 2008提供了一个Filestream类型,允许您将文件名或标识符作为指针存储在db中,并自动将图像存储在您的文件系统中,这是一个很好的场景。
如果您使用的是较旧的数据库,那么我会说,如果您将其存储为blob数据,那么您将无法通过搜索特性的方式从数据库中获得任何内容,因此最好将地址存储在文件系统上,并以这种方式存储图像。
这样还可以节省文件系统上的空间,因为您只会在文件系统上节省确切数量的空间,甚至是压缩的空间。
此外,您可以决定保存一些结构或元素,允许您在文件系统中浏览原始图像而不需要任何db访问,或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置,但保留结构,当尝试增加存储空间时,也不需要尝试将图像从db中取出。
也许,它也会允许你抛出一些缓存元素,基于常用的图像url到你的web引擎/程序,所以你也把自己保存在那里。
我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中,并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:
通过更新全局配置,将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具,如imagemagick。 在web应用程序中,您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。
如果这是基于web的应用程序,那么将图像存储在第三方存储交付网络(如Amazon的S3或Nirvanix平台)上可能会有优势。
这可能有点不切实际,但如果你正在使用(或计划使用)SQL Server 2008,我建议你看看新的FileStream数据类型。
FileStream解决了在DB中存储文件的大部分问题:
blob实际上以文件的形式存储在文件夹中。 可以使用数据库连接或通过文件系统访问blob。 备份是集成的。 迁移“就是管用”。
然而,SQL的“透明数据加密”不加密FileStream对象,因此如果考虑到这一点,最好将它们存储为varbinary。
摘自MSDN文章:
Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问。 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;因此,该内存可用于查询处理。