Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
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.
18 replies to this topic
Back to top|
|
|
#2
Guest_Jordan_*
Posted 12 January 2009 - 04:33 PM
Guest_Jordan_*
Guest_Jordan_*
-
- Guests
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.
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.
#3
Posted 12 January 2009 - 04:36 PM
Whitey
-
- Members
-
- 255 posts
Programming Professional
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?
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?
#4
Posted 12 January 2009 - 04:38 PM
mikelbring
-
- Members
-
- 118 posts
Programmer
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.
Realize the Web Web services and design.
#5
Posted 12 January 2009 - 07:37 PM
John
-
- Moderators
-
- 6,321 posts
Writes binary right handed and hex left handed
Whitey said:
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?
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).
#6
Posted 13 January 2009 - 01:21 AM
Feral
-
- Members
-
- 162 posts
Programmer
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.
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.
#7
Guest_Jordan_*
Posted 13 January 2009 - 05:56 AM
Guest_Jordan_*
Guest_Jordan_*
-
- Guests
mikelbring said:
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?
Feral said:
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.
#8
Posted 13 January 2009 - 02:46 PM
Feral
-
- Members
-
- 162 posts
Programmer
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.
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.
#9
Guest_Jordan_*
Posted 13 January 2009 - 02:52 PM
Guest_Jordan_*
Guest_Jordan_*
-
- Guests
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.
#10
Posted 13 January 2009 - 03:05 PM
Feral
-
- Members
-
- 162 posts
Programmer
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.
#11
Guest_Jordan_*
Posted 13 January 2009 - 04:26 PM
Guest_Jordan_*
Guest_Jordan_*
-
- Guests
Did they have a control panel with their hosting package?
#12
Posted 14 January 2009 - 03:48 AM
Orjan
-
- Moderators
-
- 3,299 posts
Writes binary right handed and hex left handed
If you have web sites up to that size of databases on over 1 GB, I guess the web hosting customer service can be assisting with loading an sqldump instead of using the myphpadmin way, as a one time thing, just upload the dump to the account and ask for assistance.
Everyone might not do it, but I guess many would, as they want to keep the customers. Easiest is to talk to the customer services (by phone/mail/chat) prior to ordering the web service to see if they can do it. If they can, they would be worthy having you as a customer, otherwise not. As a customer with that kind of databases, you might need even more advanced help at times, so they should be helpful at the deployment state.
Everyone might not do it, but I guess many would, as they want to keep the customers. Easiest is to talk to the customer services (by phone/mail/chat) prior to ordering the web service to see if they can do it. If they can, they would be worthy having you as a customer, otherwise not. As a customer with that kind of databases, you might need even more advanced help at times, so they should be helpful at the deployment state.
