how images/files are stored in hard disk and how orkut or any other sites links are organised..is it in differnt tables ???

Question

Friends today i was thinking about orkut structure...

There are profile,images,videos,scraps.... I think at server side there must be differnt tables like profile table,image table,video tables,scrapbook table etc.. in which each user must have his data with unique username...

Now when user login and clcik on profile link data is retrived from profile table(uinque username) and when user clcik on photos then photos are retrived for each user..

Now tell me is this going in orkut

Now for photos,when user upload his photo it must be saved in hard-disk(in nay folder in htdocs) and when user want to see these must be retrived from there..

Now my question is this,should we store full address(after upload /htdocs/uploaded image) of image in database or there is some other trick for this..

If two same name files are uploaded by 2 differnt users how query will distinguish that this image belongs to that user i think for this we must save the uploaded file with extension of username

Plz discuss these things so that we can get idea what is going behind

Answer 1

Say you have User in the database. They'll have been assigned a primary key by the database system.

So for a profile image, you could store it as:

/media/users/profile-image/<pk>.jpg

Similarly for a Photo record. It'll have a PK so you could quickly save it as:

/media/photos/<pk>.jpg

You'll notice that on many social networking (et al) sites, the filenames that get served are not the original filenames. Try it. Upload a file to Flickr and see what that filename turns into. That's because they go through a process like this.

---

If you need a more complicated filename that nobody could ever guess, you could considering hashing. A hash is an interpretation of a string that is reproducible. To stop people guessing the hashes, you add a "salt" which is an extra sting that only you know.

So "my salt" + goes in and Lhflkjh34kjb3 (or something like that) comes out.

You could do this process every time you're trying to work out what image file you need but it's quite expensive. I would suggest storing this back in the database. Note: as this example uses the primary, auto-generated key, you would need to insert the record and then update it with the filename.

---

One last point: storing the full path will get in your way eventually.

As applications grow, you inevitably need to branch out and reorganise things. If you store have a full path to the image, you'd need to change all the filenames when you restructure. It's much simpler.