所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中，而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
SQL Server 2008提供了一个两者兼备的解决方案:文件流数据类型。
像管理普通表一样管理它，并具有文件系统的性能。
其他回答
我最近创建了一个PHP/MySQL应用程序，用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。
优点:
上传的文件复制到备份服务器连同其他一切，不需要单独的备份策略(安心)。 设置web服务器稍微简单一些，因为我不需要有一个上传/文件夹，并告诉我所有的应用程序它在哪里。 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件
缺点:
mysqldump现在需要很长时间，因为其中一个表中有500MB的文件数据。 总的来说，与文件系统相比，内存/cpu效率不是很高
我认为我的实现是成功的，它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说，性能还不错。
这里的诀窍是不要成为一个狂热分子。
这里需要注意的一点是，在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?
No.
事实上，许多数据库都胜过许多文件系统，即使我们只讨论原始速度。
正确的做法是为您的精确场景做出正确的决定，要做到这一点，您需要一些数字和一些用例估计。
你的网络服务器(我假设你正在使用)是用来处理图像的，而数据库不是。因此，我会大力投反对票。
在数据库中只存储路径(可能还有文件信息)。
我将使用文件系统方法，主要是因为它具有更好的灵活性。考虑一下，如果图像的数量变得很大，一个数据库可能无法处理它。对于文件系统，您可以简单地添加更多的文件服务器，假设您正在使用NFS或kind。
文件系统方法的另一个优点是能够做一些奇特的事情，例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断，则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。
通过网络将二进制数据从数据库中取出会导致巨大的延迟问题，并且伸缩性不好。
将路径存储在数据库中，让你的web服务器承担负载——这就是它的设计目的!
