I have no idea how the big websites save the pictures on their servers. Could any one tell me how do they save the pictures that are uploaded by the users in their database?
I was thinking, maybe they would just save the file(the picture) in some path and just save that path in the databse is that right?
But I want to do it this way. Is this right? For example, a website named www.photos.com. When a user uploads a picture I would create a folder of the user name and save those pictures in that folder.
I believe we can create a directory using php file concepts. So when a new user uploads his picture or file, I want to create a directory with his name.
Example: if user name is john, I would create a directory like this on photos.com www.photos.com/john/ and then save all his pictures to this directory when he uploads a picture. Is this the right way to do this?
I have no one here that has good knowledge of saving the files to servers so please let me know how to do this? I want to do it the correct and secure way.
All big websites don't save pictures to the database; they store them on the disk. They save a reference to the picture's position in a table and then link from there.
Why? Performance.
Pulling heavy content from a database is a huge performance bottleneck. And databases don't scale horizontally that well, so it would mean an even bigger problem. All big sites use static content farms to deal with static content such as images. Those are servers that won't care less about your identity.
How do they keep the pictures really private, you might ask? They don't.
The picture's link is, in itself, the address and the password. Let's take Facebook, for example. If I store a private picture on my account, you should not be able to open it. But, as long as you have the correct address, you can.
This picture is private. Notice the filename
10400121_87110566301_7482172_n.jpg
(Facebook changes the URL from time to time, so the link may be broken)
It's non-sequential. The only way to get the picture is to know its address.
Based on a previous user photo, you can't guess the next one.
It has a huge entropy, so even if you start taking random wild guesses, you'll have an extensive amount of failures, and if you do get to a picture, you won't be able to, from there, realize the owner's identity, which, in itself, is protection in anonymity.
Edit (why you should not store images in a "username" folder):
After your edit, it became clear that you do intend to put files on disk and not on the database. This edit covers the new scenario.
Even though your logic (create a folder per user) seems more organized, it creates problems when you start having many users and many pictures. Imagine that your servers have 1T disk space. And let's also imagine that 1T is more or less accurate with the load the server can handle.
Now you have 11 users. Assume they start uploading at the same time, and each will upload more than 100GB of files. When they reach 91GB each, the server is full, and you must start storing images on a different server. If that user/folder structure is followed, you would have to select one of the users and migrate all of his data to a different server. Also, it makes a hard limit on a user who can't upload more than 1T in files.
Should I store all files in the same folder, then?
No, big sites generally store files in sequential folders (/000001/, /000002/, etc.) having an x defined number of files per folder. This is mainly for file-system performance issues.
2023 edit, the extra check:
Nowadays, most large companies also check if the user is allowed the resource/image before serving it. But the logic stays mostly the same. Apart from what's described above, before serving the resource, you do a double check on the DB to see if the user is allowed.
