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

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


当前回答

The word on the street is that unless you are a database vendor trying to prove that your database can do it (like, let's say Microsoft boasting about Terraserver storing a bajillion images in SQL Server) it's not a very good idea. When the alternative - storing images on file servers and paths in the database is so much easier, why bother? Blob fields are kind of like the off-road capabilities of SUVs - most people don't use them, those who do usually get in trouble, and then there are those who do, but only for the fun of it.

其他回答

在以前的一个项目中,我将图像存储在文件系统上,这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。

在我最新的项目中,我将图像存储在数据库中,并将它们缓存到文件系统中,它工作得非常好。到目前为止我还没有遇到任何问题。

对于大量的小图像,数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时,由于文件系统的块大小,它们每个都消耗了8kb。空间增加了400% !

有关块大小的更多信息,请参阅这篇文章: iphone文件系统的块大小是多少?

在我曾经工作过的一家公司,我们在Oracle 8i(当时是9i)数据库中存储了1.55亿张图像。7.5 tb的价值。

尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储,那么最终编写的代码会更少,结果也会更好。

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目,任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是,将它们存储在数据库中,可以方便地保存单个图像资产。如果没有可用的文件路径,并且所有图像都直接从DB中流出,那么用户就不会有发现他们不应该访问的文件的危险。

不过,这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此,DB存储并不是真正必要的。