所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
我将采用文件系统方法。不需要创建或维护带有映像的DB,从长远来看,这将为您节省一些主要的麻烦。
其他回答
在以前的一个项目中,我将图像存储在文件系统上,这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。
在我最新的项目中,我将图像存储在数据库中,并将它们缓存到文件系统中,它工作得非常好。到目前为止我还没有遇到任何问题。
我会选择两种解决方案,我的意思是……我将开发一个小组件(EJB),它将映像存储在DB中,并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时,这个DB才会更新。然后,我还将该路径存储在业务DB中。
从应用程序的角度来看,我将始终使用文件系统(从业务DB检索路径),通过这种方式,我们将修复备份问题,并避免可能的性能问题。
唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜,拜托!
当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份,web服务器,甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中,那么您需要编写自己的代码来解决这些问题。
在数据库中只存储映像的文件路径的问题是,不能再强制数据库的完整性。
如果文件路径所指向的实际映像变得不可用,则数据库会不知不觉地出现完整性错误。
考虑到图像是被寻找的实际数据,并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失),而不必与某种文件系统(如果文件系统是独立访问的,图像可能会突然“消失”),我倾向于将它们直接存储为BLOB或类似的文件系统。
如果你需要在文件系统中存储大量的图像,需要考虑以下几点:
备份和恢复。你如何保持图像同步。 文件系统的性能。这取决于您正在做的事情和文件系统,但您可能希望实现一个散列机制,这样您就不会有一个包含数十亿个文件的目录。 复制。您是否需要在多个服务器之间保持文件同步?