Creating a User Gallery

[Whitey]

Okay well i am creating a site which will have a user gallery. AKA Each member will be able to upload their photos. (Kinda like myspace).

Now, a few questions.
When they upload their image. Should i encrypt the name? and/or Randomize the name?

When they upload, how can i check to see if that number already exist or not?

But when i do this, its going to be like the following

image.php?userID=theiruserid&picID=picID or w/e

so that it will only find the pic for each userid that was assigned to it.

[Jordan]

Instead of worrying about filenames (and permissions) why don't you store the images in a database? You can then have a row:

imageID | userID | image

The image colum would be a blob and you would store the image there. You could then assign the userID to that column and make the imageID a primary auto-increment field.

[Whitey]

i was gonna store it in the DB.
Exactly how you did but my main question was. Could that become a problem doing the imageID as a auto-increment or should i make it random number, letters, etc?

[mikelbring]

I was told that filesystem is better for storing images. I store my images in a filesystem but keep records of them in the database. Like to see your opinion on that.

[John]

i was gonna store it in the DB.
Exactly how you did but my main question was. Could that become a problem doing the imageID as a auto-increment or should i make it random number, letters, etc?

If you go with the database approach, an auto-incrementing key is the best option. This ensures every entry will be unique, by simply using a random number, you are taking the chance of creating a duplicate key. If you go with the file system approach, I would append a timestamp to each image, this would also ensure that the file name is unique (assuming the user doesnt upload the same file at during same second).

[Feral]

You want to be careful when storing the images in the database, if you ever have to move to a different server the size of the database can make in a headache.

I always use a filesystem+database approach. The images are uploaded to a particular directory and renames such as myimage.jpg_1_15_1231838105 where 1 is the user id, 15 is the images id number from the database, and 1231838105 is the time stamp for when the image was uploaded.

I then store the information in the database table that contains rows imageId, userId, timeStamp. When an image is requested i use a php file and the request is made like image.php?userid=1&imageid=15, the script pulls the time stamp from the database and sent to the browser.

This gives the freedom to make attachments or watermarks on the fly.

[Jordan]

I was told that filesystem is better for storing images. I store my images in a filesystem but keep records of them in the database. Like to see your opinion on that.

I've never heard this. Any reason why a filesystem would be better?

You want to be careful when storing the images in the database, if you ever have to move to a different server the size of the database can make in a headache.

This doesn't really seem logical. If you store the images in the database or on a filesystem you will still have to move the same amout of "space" to move. In fact, storing as files could mean you need to transfer thousands and thousands of files while storing in a database you simply do one dump and import.

[Feral]

Yes but when you are dealing with phpmyadmin which on most servers has a import file size of +/- 50,000 KiB which can be exceeded by a couple thousand posts on a popular message board. Adding in the extra blob field for to store the text version of the image you database can get over 1Gig in size pretty fast.

I had to move a site to a new server a couple weeks ago that stored there images in the database, the attachments table alone was 1.6Gigs. In the case of this site the images where converted to a hex format and inserted into a blob in the database, every time an image was requested the image had to be be recreated from the hex and sent to the browsers. Which also turned out to be why the site ran slowly on the clients old server, causing the reason for the move to a more powerful server.

I ended up having to write a tool to split the sql file into smaller manageable chunks to be uploaded. If the site was using a file system this would not have been necessary since I only would have had to upload the images and walk away.

[Jordan]

Wow, that sounds painful. Using phpMyAdmin could limit you but I assumed any transfer of databases would be done using mysqldump and the mysql console program. I've moved site dbs around 4gb easily using those tools. If you don't have root access, no SSH access and your webhost control panel offers no way of doing this (I know cpanel and plesk both offer the method), I could see how you would dislike the method.

[Feral]

Normally I would have uses ssh but the client had gotten burned my another freelancer and was very unwilling to give out information that he didn't feel absolutely necessary.