处理内容管理系统中的图像和文件附件
假设：Microsoft 堆栈（ASP.NET；SQL Server）。
某些内容管理系统通过将用户生成的内容（图像、文件附件）存储在文件系统中来处理这些内容。其他人将这些项目存储在后端数据库中。
两者的一些示例：
- 在文件系统中：Community Server、Graffiti CMS
- 在数据库中：Microsoft Sharepoint
我可以看到每种方法的优缺点。
在文件系统中
- 轻量级
- 避免数据库膨胀
- 备份和恢复可能更简单
在数据库中
- 所有内容都集中在一个存储库（数据库）
- 完全分离关注点（内容与格式）
- 更轻松地部署网站（例如直接从 Subversion 存储库）
什么是最好的方法，为什么？将用户文件保留在数据库中有何优点和缺点？还有另一种方法吗？
我在社区维基上提出这个问题是因为它有点主观。
Assumptions: Microsoft stack (ASP.NET; SQL Server).
Some content management systems handle user-generated content (images, file attachments) by storing it in the file system. Others store these items in the back end database.
Some examples of both:
- In the filesystem: Community Server, Graffiti CMS
- In the database: Microsoft Sharepoint
I can see pros and cons of each approach.
In the filesystem
- Lightweight
- Avoids bloating the database
- Backup and restore potentially simpler
In the Database
- All content together in one repository (the database)
- Complete separation of concerns (content vs format)
- Easier deployment of web site (e.g. directly from Subversion repository)
What's the best approach, and why? What are the pros and cons of keeping user files in the database? Is there another approach?
I'm making this question Community Wiki because it is somewhat subjective.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您使用的是 SQL Server 2008 或更高版本，则可以使用 FileStream 功能来获得两全其美的效果。也就是说，您可以从数据库访问文档（用于查询等），但仍然可以通过文件系统（使用 SMB）访问文件。 更多详细信息请参见此处。
Erick
If you are using SQL Server 2008 or higher, you can use the FileStream functionality to get the best of both worlds. That is, you can access documents from the database (for queries, etc), but still have access to the file via the file system (using SMB). More details here.
Erick
我选择文件系统是因为它使就地编辑文档变得更加容易，也就是说，当用户编辑文件或文档时，可以将其保存在加载的位置，而无需程序或用户的干预。
I picked the file system because it made editing of documents in place easier, that is when the user edits a file or document it can be saved in the location it is loaded from with no intervention by the program or user.
IMO，就目前数据库中可用的功能而言，文件系统是更好的选择。
使用文件系统的最大缺点是可能会出现孤立文件以及使文件上的数据库信息与磁盘上的实际文件保持同步。诚然，这是一个巨大的问题，但在像 FILESTREAM 这样的解决方案变得更加灵活之前，这是您必须付出的代价。
IMO, as of right now with the current functionality available in databases, the file system is the better choice.
The biggest downside with using the file system is the potential for orphaning files and keeping the database information on files in sync with the actual files on disk. Admittedly, this is a huge issue but until solutions like FILESTREAM are more flexible, it is the price you have to pay.
实际上是3号门查克。
我认为将图像存储在数据库中是个坏消息，除非您需要将它们保密，否则，只需将它们放在 CDN 上并存储图像的 URL 即可。我已经构建了一些大型电子商务网站，并将负载放在像 Akumai 或 Amazon Cloudfront 这样的 CDN 上是显着加快网站速度的真正好方法。我不太喜欢为了提供图像而消耗带宽、CPU 和内存。如今，由于 CDN 如此便宜，这似乎是一种愚蠢的资源浪费。此外，它确实允许部署不关心，因为您的东西已经位于全球可访问的区域中。您可以查看我的个人资料，了解我做过的网站，并了解他们如何使用 CDN 来卸载静态请求。这是有道理的，如果你可以 gzip 它会变得更好。
Actually its door #3 Chuck.
I think storing images in the database is bad news unless you need to keep them private, otherwise, just put them on a CDN and store the URLs of the images instead. I've built some huge sites for ecommerce and putting the load on a CDN like Akumai or Amazon Cloudfront is a real nice way to speed up your website dramatically. I'm not a big fan of burning your bandwidth, CPU and memory for serving up images. Seems a silly waste of resources now days since CDNs are so cheap. Also, it does allow deployment to not care because your stuff is already in a globally accessible region. You can take a look at my profile to see the sites I've done and see how they are using CDNs to offload static requests. Just makes sense and gets even better if you can gzip it.