所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
I have worked with many digital storage systems and they all store digital objects on the file system. They tend to use a branch approach, so there will be an archive tree on the file system, often starting with year of entry e.g. 2009, subdirectory will be month e.g. 8 for August, next directory will be day e.g. 11 and sometimes they will use hour as well, the file will then be named with the records persistent ID. Using BLOBS has its advantages and I have heard of it being used often in the IT parts of the chemical industry for storing thousands or millions of photographs and diagrams. It can provide more granular security, a single method of backup, potentially better data integrity and improved inter media searching, Oracle has many features for this within the package they used to call Intermedia (I think it is called something else now). The file system can also have granular security provided through a system such as XACML or another XML type security object. See D Space of Fedora Object Store for examples.
其他回答
如果你需要在文件系统中存储大量的图像,需要考虑以下几点:
备份和恢复。你如何保持图像同步。 文件系统的性能。这取决于您正在做的事情和文件系统,但您可能希望实现一个散列机制,这样您就不会有一个包含数十亿个文件的目录。 复制。您是否需要在多个服务器之间保持文件同步?
不经常编辑的小静态图像(不超过几兆)应该存储在数据库中。这种方法有几个好处,包括更容易移植(图像与数据库一起传输),更容易备份/恢复(图像与数据库一起备份)和更好的可伸缩性(一个包含数千个小缩略图文件的文件系统文件夹对我来说听起来像是可伸缩性的噩梦)。
从数据库提供图像很简单,只需实现一个http处理程序,将从DB服务器返回的字节数组作为二进制流提供服务。
SQL Server 2008提供了一个两者兼备的解决方案:文件流数据类型。
像管理普通表一样管理它,并具有文件系统的性能。
如果您没有使用SQL Server 2008,并且有充分的理由将特定的映像文件放在数据库中,那么您可以采用“两者兼备”的方法,将文件系统用作临时缓存,并将数据库用作主存储库。
例如,您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上,并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。
尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储,那么最终编写的代码会更少,结果也会更好。