Geek Answers Handbook

Processing images and file attachments in a content management system

Assumptions: Microsoft stack (ASP.NET; SQL Server).

Some content management systems process user-created content (images, file attachments), storing it in the file system. Others store these items in a database on the back panel.

Some examples of both:

  • File System: Community Server, Graffiti CMS
  • Database: Microsoft Sharepoint

I see the pros and cons of each approach.

In file system

  • A light weight
  • Prevents database bloat
  • Backing up and restoring is potentially easier

In the database

  • All content together in one repository (database)
  • Complete separation of problems (content in format)
  • Easier website deployment (e.g. directly from Subversion repository)

What is the best approach and why? What are the pros and cons of saving user files in a database? Is there any other approach?

I am asking this question to the Community Wiki because it is somewhat subjective.

+4
source share
4 answers

If you are using SQL Server 2008 or higher, you can use 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 through the file system (using SMB). More details here .

Eric

+1
source

I chose the file system because I simplified the editing of documents, that is, when a user edits a file or a document, it can be saved in the place where it is downloaded, without the intervention of a program or user.

0
source

IMO, as of now, with existing functionality available in databases, a file system is the best choice.

  • The file system has no file size limits, and with content it can easily be file sizes larger than 2 GB.
  • This makes the database size much smaller, which means less pressure on the memory.
  • You can design your system to use UNC and NAS, or even cloud storage, where you cannot do it with FILESTREAM.

The biggest drawback with using the file system is the ability for orphaned files and storing database information about files that are synchronized with actual files on disk. Admittedly, this is a huge problem, but while solutions like FILESTREAM are more flexible, this is the price you have to pay.

0
source

Actually his door number 3 Chuck.

I think storing images in a database is bad news if you don't need to keep them secret, otherwise just put them on a CDN and save the image URLs. I have created some huge e-commerce sites, and downloading onto a CDN like Akumai or Amazon Cloudfront is a great way to speed up your site. I am not a big fan of burning bandwidth, processor, and memory for serving images. It seems like a waste of resources right now, since CDNs are so cheap. In addition, this allows the deployment not to be taken care of because your material is already in a globally accessible region. You can look at my profile to see the sites that I made and see how they use CDN to offload static requests. It just makes sense and gets even better if you can gzip it.

0
source

More articles:


All Articles