所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
假设:应用程序是基于web的
我很惊讶没有人真正提到这一点……委托给其他专家->使用第三方映像/文件托管提供商。
将文件存储在付费的在线服务上,比如
Amazon S3 Moso云存储
另一个StackOverflow线程在这里讨论这个。
这篇文章解释了为什么你应该使用第三方托管提供商。
太值得了。它们能有效地储存。没有带宽从你的服务器上传到客户端请求等等。
其他回答
如果您没有使用SQL Server 2008,并且有充分的理由将特定的映像文件放在数据库中,那么您可以采用“两者兼备”的方法,将文件系统用作临时缓存,并将数据库用作主存储库。
例如,您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上,并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。
我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。
这里有几个问题:
database storage is usually more expensive than file system storage you can super-accelerate file system access with standard off the shelf products for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization. things like web servers, etc, need no special coding or processing to access images in the file system databases win out where transactional integrity between the image and metadata are important. it is more complex to manage integrity between db metadata and file system data it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem
我将采用文件系统方法。不需要创建或维护带有映像的DB,从长远来看,这将为您节省一些主要的麻烦。
当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份,web服务器,甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中,那么您需要编写自己的代码来解决这些问题。
我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的,在工作流结束时被删除。如果有任何形式的长期存储,我们肯定会选择存储文件路径。
还应该注意的是,我们在内部使用客户端/服务器应用程序,因此不需要担心web界面。