所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
正如有人已经提到的,“视情况而定”。如果数据库中的存储被认为是文件系统的1对1替代方案,那么它可能不是最佳选择。
但是,如果数据库后端将提供额外的值,而不仅仅是blob的序列化和存储,那么它可能是真正有意义的。
You may take a look at WKT Raster which is a project aiming at developing raster support in PostGIS which in turn serves as a geospatial extension for PostgreSQL database system. Idea behind the WKT Raster is not only to define a format for raster serialization and storage (using PostgreSQL system), but, what's much more important than storage, is to specify database-side efficient image processing accessible from SQL. Long story short, the idea is to move the operational weight from client to database backend, so it take places as close to storage itself as possible. The WKT Raster, as PostGIS, is dedicate to applications of specific domain, GIS.
要获得更完整的概述,请查看该系统的网站和演示文稿(PDF)。
其他回答
你的网络服务器(我假设你正在使用)是用来处理图像的,而数据库不是。因此,我会大力投反对票。
在数据库中只存储路径(可能还有文件信息)。
我负责一些管理许多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
在以前的一个项目中,我将图像存储在文件系统上,这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。
在我最新的项目中,我将图像存储在数据库中,并将它们缓存到文件系统中,它工作得非常好。到目前为止我还没有遇到任何问题。
我最近创建了一个PHP/MySQL应用程序,用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。
优点:
上传的文件复制到备份服务器连同其他一切,不需要单独的备份策略(安心)。 设置web服务器稍微简单一些,因为我不需要有一个上传/文件夹,并告诉我所有的应用程序它在哪里。 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件
缺点:
mysqldump现在需要很长时间,因为其中一个表中有500MB的文件数据。 总的来说,与文件系统相比,内存/cpu效率不是很高
我认为我的实现是成功的,它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说,性能还不错。
您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。
如果你有一个小的,单用户的消费应用程序,那么我会说DB。我有一个DVD管理应用程序,使用文件系统(在程序文件中),它是一个PIA备份。我希望他们每次都能把它们存储在数据库中,让我选择保存文件的位置。
对于一个更大的商业应用,我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上,以一种编码格式(以处理大量文件的FS问题),基于县指定的仪器编号。这在另一个方面是有用的,因为图像可以在DB记录之前存在(由于他们的工作流程)。
和大多数事情一样:“这取决于你在做什么”