Forum Moderators: coopster
Just that i think you might want to manage some subdirectories in your pictures folder, like with every directory containing maybe like 500 max images. Imagine having to FTP to a directory (for any reason) that contains 50,000 Images, easily capable to hang many of the FTP clients even just while listing directory entries
Maybe i could categorize them by letter and number. Users that start with an "a" go to /A/*.jpg
And so on. Since there are 25 letters and 10 numbers, i should have 35 directories.
50.000 images divided into 35 directories is around 1400... that's more manageable for the ftp client.
and I, too, vote for a directory. Agreed, it's nice to have everything stored in one place so that a db-move is all you need etc pp but there's another thing: you'll need a php-script to give an image to the client, that's one extra script to run for every image you display and that can add up pretty fast. direct file delivery by the webserver is much, much faster than executing a php-script that connects to a database, queries a table, gets a row and prints the content of a blob.
If i would like to get the numeric value of the ID of that user, i should connect to the database first... and i want to avoid that.
How could i transform "BEA41341" to an integer so i can apply your solution?
You can convert the alphabetic character into a predefined value. Like
A=1, B=2, C=3 , D=4, E=5, ........ so on
Then you can easily convert BEA41341 into 25141341. May be there is another good solutions. But right now i think that when i will get a new one I must let you know.
Thanks
Mahabub
Ask yourself if you would be happy with having all the user data, but losing all the images?
We have a very DB-intensive site. So we prefer to let the OS handle image serving/backing up. Also, for a restore, I'd rather have a quick restore of all the data instead of a longer period to restore the data + images together.
As somewhat of a compromise, I guess you could store data in one database and images in another.
[edited by: LifeinAsia at 5:20 pm (utc) on Dec. 17, 2008]
My reasoning for this:
-> Small files, shouldn't take up too much DB space
-> I don't wanna back up 50k+ avatar files regularly...*shivers*
-> User maintenance is made pretty simple.
1) User opts out, delete his record. No need to mess with deleting a file.
2) User updates avatar, no need to find the previous, delete it, and upload the new one...just simply update a field. (I guess this one really depends on how you plan on handling/naming your avatar files. Because copy() could be used to just overwrite whatever was associated with account X.)
Now, I wouldn't go hog wild and store big image files in my DB, but a 50x50 pic seemed alright.
-M. Cold
basically all apart from IE6 and IE7
that's like saying "all but the majority" ;)
every advantage is also a disadvantage in that decision: mysql-dumps take longer and are bigger, unless you want to rely on doing incremental dumps, but the lazy folks like me just put a complete dump into the backup and are happy. files are easy to be backed up with rsync or whatever backup solution you use for your regular files.
The images will be saved as JPEGs at 480x320... multiply that by 50k times... and the DB will be too big.
I think i'll put them on directories and i will follow janharder's recommendation of placing 1000 pictures per directory by using. I did tweak his code a little, and i got this:
$id = $_GET['id'];
$dir = str_pad(($id - ($id % 1000))/1000,4,'0',STR_PAD_LEFT);
That way:
* user IDs 1 through 999 will be saved on directory '0000'
* user IDs 1000 through 1999 will be saved on directory '0001'
and so on...
Of course i wont be able to use the PIN itself... i will have to use the ID associated to that PIN, and save the images as %id%.jpg