CODEWITHSUNDEEP
c#asp.netimagesql-server-2008content-management-system
Unknown Coder
Unknown Coder

Reputation: 1740

Image management approaches for CMS

I'm working on CMS implementation using ASP.Net, C# and SQL server 2008. for Image management I've 2 approaches in hand.

1] Storing image in a folder, and reading them by preparing a Dataset, that holds the Image Path and Name. (here I can't manage the Alternate text dynamically, as I can get only path and image name)

2] Storing image in a folder, and all attributes in a Table (Id, Name, Path, Alternate Text etc).

So, Which is the best and optimized approach? or else give me any other approach which is better than these two.

Upvotes: 1

Views: 826

Answers (2)

Lilith River
Lilith River

Reputation: 16468

Amazon S3 is now the gold standard - it scale easily and keeps both your app filesystem and db slim. NTFS doesn't scale past 100K files well, and IIS and ASP.NET don't handle over 400 folders well, especially over a SAN.

@j_mcnally Microsoft's official stance is to avoid putting images in the DB. It's fast, but slower than NTFS, and uses RAM like mad, and prevents efficient caching and file streaming by IIS.

Using MS SQL or a key-value store to hold the S3 Image URLs, but storing the actual data on S3 has a lot of advantages - practically infinite scalability, inexpensive bandwidth costs, and your ASP.NET server can focus on being responsive instead of getting bogged down with static files.

On an related note, are you using single-source imaging? CloudFront is extremely inexpensive, and it only takes about five minutes to get it set up with the imageresizing.net library. Then you can request images like this:

http://images.mysite.com/folder/image.jpg;width=300;height=300;mode=crop

The master image will get retrieved from S3, resized on the .NET server, and edge-cached by CloudFront. Fast, efficient, and cheap. And most importantly, agile.

Upvotes: 1

j_mcnally
j_mcnally

Reputation: 6968

#2 its basically the gold standard for storing images.

a 3rd but less preferred option is to save the actual image as blob or even worse a base64 encoded string in the database. This requires you to save the mime-type and either use a data-uri or a web service to serve the image back as binary content. (This is not a great idea, it adds alot of un-indexable overhead to your DB, although you may have an extreme use-case where this seems like a good idea. It can be useful if you are back-ending a mobile app where you want to serve an asset along with your record in an api call, but even then its not always a good idea.

Upvotes: 2

Related Questions