处理内容管理系统中的图像和文件附件

Question

假设：Microsoft堆栈（ASP.NET; SQL Server）。

某些内容管理系统通过将其存储在文件系统中来处理用户生成的内容（图像，文件附件）。其他人将这些项目存储在后端数据库中。

两者的一些例子：

• 在文件系统中：社区服务器，Graffiti CMS
• 在数据库中：Microsoft Sharepoint

我可以看到每种方法的优点和缺点。

在文件系统

中

• 轻型
• 避免膨胀数据库
• 备份和恢复可能更简单

在数据库中

• 所有内容集中在一个存储库（数据库）
• 完全分离关注点（内容与格式）
• 更容易部署网站（例如直接从Subversion存储库）

什么是最好的方法，为什么？将用户文件保存在数据库中的优缺点是什么？还有另一种方法吗？

我正在提出这个问题社区Wiki，因为它有点主观。

Answer 1

如果您使用的是SQL Server 2008或更高版本，则可以使用FileStream功能充分利用这两个方面。也就是说，您可以从数据库访问文档（用于查询等），但仍可以通过文件系统（使用SMB）访问该文件。 More details here.

埃里克

Answer 2

我选择了文件系统，因为它使文档的编辑更加容易，也就是说，当用户编辑文件或文档时，它可以保存在加载的位置，而不需要程序或用户的干预。

Answer 3

IMO，截至目前，数据库中目前的功能可用，文件系统是更好的选择。

1. 文件系统对文件大小没有限制，对于内容，这可能很容易就是大于2 GB的文件。
2. 它使数据库大小更小，这意味着内存压力更小。
3. 您可以将系统设计为使用UNC和NAS甚至云存储，而不能使用FILESTREAM进行此操作。

使用文件系统的最大缺点是可能会出现孤立文件，并使文件上的数据库信息与磁盘上的实际文件保持同步。不可否认，这是一个巨大的问题，但在FILESTREAM等解决方案更加灵活之前，这是您必须付出的代价。

Answer 4

实际上它的门＃3 Chuck。

我认为在数据库中存储图像是个坏消息，除非您需要将它们保密，否则，只需将它们放在CDN上并存储图像的URL即可。我已经为电子商务建立了一些大型网站，并将负载放在像Akumai或Amazon Cloudfront这样的CDN上，这是一种非常好的方式来大大加快您的网站速度。我不是为了提供图像而燃烧带宽，CPU和内存的忠实粉丝。由于CDN如此便宜，现在似乎是对资源的愚蠢浪费。此外，它确实允许部署不关心，因为您的东西已经在全球可访问的区域。您可以查看我的个人资料，查看我已完成的网站，并了解他们如何使用CDN卸载静态请求。如果你可以gzip它就会有意义并且变得更好。