Based on my understanding, there are 3 ways I could do it.

  1. Filestream
  2. File-system
  3. Store images in the database itself

I am having a hard time deciding which one would be more appropriate for me.

I will have a lot of more reads than writes, but writes wouldnt be completely infrequent either.

All images would be less than 1 MB in size for sure, but they would usually be around 50KB.

link|improve this question

71% accept rate
On stackoverflow...? – gbn Feb 16 '10 at 4:43
Yes, they closed my thread there, because they thought it belongs here. – progtick Feb 16 '10 at 6:46
you might also ask on the ask.sqlservercentral.com stackexchange. This isn't an admin decision per se. This is application design. – Jim B Feb 16 '10 at 12:49
feedback

2 Answers

up vote 2 down vote accepted

Don't store your images in the database, or binary data at all for that matter if it can be avoided. It doesn't belong in a database. Store the images in your filesystem and dump a pointer into your database with all the associated metadata (file type, size, date, etc.).

When doing this, you'll need to take a couple precautions. First, you'll need to make sure to avoid filename collisions somehow (perhaps save the file using a file id substituted for the real filename). Second, make sure you won't end up with too many files in a single directory - this can lead to performance issues down the road.

link|improve this answer
feedback

The answer is, it depends. I would need to know more about the exact nature of your application. You are on the edge of using filestream vs storing images inthe database. See this MSDN article for a complete discussion of the pros and cons of each approach. I think the biggest decision point will be the performance of frequent small updates.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.