views:

11

answers:

2

Although it may not seem like that but there is a little questions about this subject. I am not asking if I should use DB or filesystem, the file system it is, but I am asking what is the best way of organizing pictures in file system that will be used with asp.net application? I am talking about tens or even hundreds of thousands of picture.

To elaborate a question a bit.

  • Where should repository be located, create another VD in IIS or in application VD, or somewhere outside IIS?
  • How to organize file patsh, put them all in one folder or create subfolders. If so how to name all those folders?
  • How to handle multiple sizes of the same image? where to locate them?
  • How to sync folders and images with database?
  • What else crosses your mind, and you think it's important..

I've done something myself allready, but I am asking if someone had some experience with this. Maybe it could be done better yours way.

I put things like this

  • I stored pictures in IIS folder, because storing them outside of iis make them unable to use in web, because of paths. You cannot use file path in web, it must be virtual file path.

    http://images/1.jpg istead of C:\images\1.jpg

  • in the root I had subfolder for each picture size

    root- +400x300 +600x400 +1024x768

  • Named images by id from database. If the ImageID from database is 45678909, the name of picture is 45678909.jpg an it's location is

    VD\images\400x300\45\67\89\45678909.jpg

    VD\images\600x400\45\67\89\45678909.jpg

I sliced the picture name two by two, and create subfolders. the point was not to have more than 100 files in folder. Was this good idea or stupid one? How would you organize this? For person, this organization with tons of folder is not easy to use.

  • Name of the image with its relative path I saved in database table with description and time of insert etc. path: 45\67\89\45678909.jpg

Any suggestions or improvements?

Thanks :)

A: 

1) I don't know ASP or IIS, so I can't help you here. I store images on Amazon S3, but I don't know if that's relevant to your case.

2) Try to organize photos based on their model, then ID. So if images are user avatar images, your path would look like avatars/ID/image.

3) If you create multiple images of different sizes, try assigning a name to each size. For instance, you have "original" image, "thumbnail" image (90x90), and "preview" image (400*300). This way you can store the different sizes either like avatars/ID/image_SIZE or avatars/ID/SIZE/image.

4) If you are following the way I mentioned, then you only need to store information for the original image in your DB, and from that you can derive all other images at runtime.

All those points are from the amazing PaperClip plugin for Ruby on Rails. Take a look at it for further guidance on how they store files and attachments.

Faisal
+1  A: 

Your last solution seems a perfectly good solution to me. File access can slow down with too many files in one folder, more than 1000 say, so sticking to 100 is good.

In terms of syncing, you'd just need a script that runs periodically that queries the database for all the images that should be there, and deletes the redundant one. If you're not tight on disk space, then you don't need this.

There may come a time when you'd want the images on another server for better scalability. The only thing I might do is set up a subdomain for your images, e.g. images.yourdomain.com. Even if you point it at the same server, it's very easy to shift your images to a faster file server should you need to.

Tim