所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。

你认为优点和缺点是什么?


当前回答

我将采用文件系统方法。不需要创建或维护带有映像的DB,从长远来看,这将为您节省一些主要的麻烦。

其他回答

和大多数问题一样,这并不像听起来那么简单。在某些情况下,将图像存储在数据库中是有意义的。

存储的图像 动态变化,比如发票和你想要的 因为它是在1月1日 2007年? 政府希望你保持6年的历史 存储在数据库中的映像不需要不同的备份策略。存储在文件系统上的映像可以 如果图像在数据库中,则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。这需要一个非常坚定的管理员去窥探数据库提取图像

另一方面也有相关的问题

需要额外的代码来提取 然后播放图像 延迟可能是 比直接文件访问慢 数据库服务器负载过重

如果您使用Teradata,那么Teradata Developer Exchange有一篇关于加载和检索lobs和blobs的详细文章。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份,web服务器,甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中,那么您需要编写自己的代码来解决这些问题。

文件存储上的图像是最好的选择,并将元数据存储在数据库中作为补充。从web服务器的角度来看,提供东西的最快方法是直接指向它。如果它在数据库中——比如Sharepoint——你就有ADO的开销。用网把它拉出来,流出来,等等。

Documentum -虽然臃肿和复杂-有它的权利,文件是在共享和可供您决定如何存储它们-磁盘上的服务器,SAN, NAS,无论什么。Documentum的策略是根据数据库中的主键对文件夹和文件名进行编码,从而将文件存储为树状结构。DB成为了解什么文件是什么文件和加强安全性的资源。对于大容量系统,这种方法是一种很好的方法。

在处理元数据时也要考虑这一点:如果您需要更新元数据语料库的属性,DB是您的朋友,因为您可以使用SQL快速执行更新。使用其他标记系统,您手头没有简单的数据操作工具

这取决于你要存储的图像数量和它们的大小。我曾经使用数据库存储图像,我的经验是相当不错的。

在我看来,使用数据库存储图像的优点是,

A.你不需要FS结构来保存你的图像 B.当存储更多的项时,数据库索引比FS树执行得更好 C.智能调优的数据库在缓存查询结果方面表现良好 D.备份很简单。如果您设置了复制,并且内容从用户附近的服务器传递,那么它也可以很好地工作。在这种情况下,不需要显式同步。

如果你的图像很小(比如< 64k),并且你的db的存储引擎支持内联(记录中)blob,它可以进一步提高性能,因为不需要间接(实现了引用的局部性)。

当您处理少量大尺寸图像时,存储图像可能是一个坏主意。在db中存储图像的另一个问题是,像创建、修改日期这样的元数据必须由应用程序处理。