I'm building an app where each user can have multiple profiles. Users can upload multiple photos for each profile, etc.
The folder structure will be something like
public_html/
upload/
user-123/
profile-199/
profile-321/
images/
123423.png
I'm going to have a one to many relationship between each profile and each photo, but I'm trying to see how I should flag a photo as special and the users "profile photo".
My proposed table structure is something like this
id
profile_id
filename (or maybe extension only, since filename will most likely just be the primary id for that photo)
profile (boolean field of whether this a profile pic or not)
date_added
How should I treat special images, like profile pictures?
Edit: Sorry if I wasnt clear. I want each user to be able to have multiple profiles, each profile to have many photos. Just like for Facebook, you can have many photos, but only one profile pic at any time.
That would work but it would have a problem that more than one photo could be marked as a profile photo unless you take special care to prevent this.
An alternative design is to have a table with columns user_id and special_photo_id where the photo_id is a foreign key into the photos table. This has a slightly different issue: now it is possible to have a special photo that doesn't belong to the user.
You could have a field in your users table(where its username and other info is stored) with a profile_id field init pointing to the profiles table. That way you get one possibility for the profile and away to identify it.
Thinking about it that will only work if you do have a users table and a separated profiles table.
How about the image table looks like this:
id
profile_id
filename
date_added
and add the column 'profile_image_id' in the profile table? This will be your special image's id.
I imagine you are going to have a lot more non-special images than special. So, most of the time the field 'profile(boolean)' that you proposed will be 0.
Edit: I believe #Iznogood is saying the same thing.
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
I'm building a simple login/registration feature, and I'm having a little trouble.
The issue is this, the user system I'm designing is supposed to accommodate different types of users, like (Blue users, Red users, Black users etc). So I was considering porting their different user data to separate database tables, and even giving them separate registration pages, because the content they would view on the site would vary depending on their color.
For example:
Blue Users:
INSERT 'username' INTO `blue` where...
Red Users:
INSERT 'username' INTO `red` where...
But I want to know if there's a way to log them into the site from the same login page without resorting to sending them to different pages when they want to login. I tried the following:
"SELECT `id` FROM `blue`,`red` WHERE `username`...
but it did not work, so I'm asking if there's a way to register the different user types on the same page and log them in on the same page while still giving them their different content.
One problem is probably that the "id" value is an auto-incremented primary key, right? Therefore it would be unique to only the table that they are in, but not over all tables (blue, red, black)
You would then always have to make sure to have unique usernames and ids over all groups or let them select what group they are when they log in and then only load data from that table.
If you have already solved the uniqueness problem, you should be able to simply use the union querys already suggested by other users. You can't use blue, red, because that is short for blue JOIN red, which of course will only result in data where columns with the same name are equal across blue and red.
Assuming that the user can be just in one table, you could use UNION...
SELECT id FROM blue WHERE username...
UNION
SELECT id FROM red WHERE username...
... but as a piece of advice, if user info is the same for all, you better have one table for usertypes and another for users, and link them with a foreign key...
USERTYPES TABLE
id_usertype
usrt_name
USERS TABLE
id_user
id_usertype (this should be a foreign key)
usrname
I hope it helps.
I have a website coded in html/css and a bit of js and jQuery.
MySql is my choice of database.
I have a login-system and users can create their own accounts on my site.
The problem is, that I'm trying to somehow restrict users so that only user A can view content (in this case, images) that I have specified for him. User B can only view its own content and so on.
I tried to mess with Role Based Access Control in php but I failed.
I'm looking for a simple solution. I have one (1) table with users where the "user_id" is the primary key.
Isn't there a way to do something like this?
if(user_id == 1) {
Do somethnig here
}
Charles, as commented there are many "open source content management systems" available that do this out of the box - I personally favour http://www.silverstripe.org/
However your question is about how to structure your database and I would recommend a "many many" relationship ( https://en.wikipedia.org/wiki/Many-to-many_(data_model) ). To create this you will need a table in the middle that stores all the id's from both ends.. e.g.
member - id - plus other fields
member_image - contains only member_id and image_id
image - id - plus other fields
to complete your code example...
$sql = "SELECT 1 FROM member_image WHERE member_id = $iMemberID AND image_id = $iImageID"
...it would be "if" the above SQL returned a row or not they member can access that image
I have a site that allows users to vote on images. Each image has a unique id number. For voting restriction purposes, I'd like to keep track of what each user has liked. How would I go about setting up a row in the USERS table that holds all the different id numbers of the images liked by this particular user?
You should not have all this information in your users table. I persume that you have one table with all your images and one with all your users. Create a table called "user_image_like" for example. And store "user_id" and "image_id". When the user presses like on the image your script will add "user_id" and "image_id" to the table.
When you wan't to see all images liked by a user you can easly get this by a simple sql query.
If you want to store such information in one table and in one field, I have the answer for you.
You can use either ways:
Store the IDs in a CSV format. When you fetch these values you can deal with them as you deal with a CSV file.
Store the IDs in an XML format. Then, you deal with it as any other XML file.
Regards,
This is a Many to Many relation. i.e. one user can like multiple Images and one image can be liked by multiple users.
According to normalization standards you should use these relation in separate table with user_id and image_id. whenever user like an image add a row to this table.
If you still want to store it in single table (users) then store ids in CSV format. be sure to store only unique image ids for each row.
Check this article
http://www.tonymarston.net/php-mysql/many-to-many.html
I have a MYSQL database of photo galleries;
each row contains a field with the list of images included in that gallery, eg:
1,5,134,13,5
these are the IDs of the photos. The same image_id could be included in other galleries.
When I delete a photo, I need to remove the corresponding id from the galleries that contain it.
What's the best way to do this in PHP?
I thought of EXPLODEing the field into an array, remove the value and then IMPLODE back and update the DB, but I'm pretty sure there's a better way?
thanks,
Patrick
THANKS Galen & all.
I'm a newbie and don't know much (=anything) about normalization. if I understand correctly, you're suggesting to have 2 tables: 1 with all the info about the photo (eg, image_id, name, caption, etc..) and another table with just a list of galleries that use that photo, eg:
gallery_id | image_id
1 3
1 7
1 5
2 3
2 8
so by deleting from this table WHERE image_id=3, i would remove that photo from two galleries.
In this case, however, I would I manage the order of photos? Having a string allowed me to have an ordered list of photos.
This is the exact reason why you normalize your tables. Then you could just run the query
delete from images where image_id=5;
delete from imageXgallery where image_id=5;
Where the images table contains all the image info. The imageXgallery table just contains image to gallery references.
I suggest you read up on normalization and update your tables.
EDIT: To allow for image ordering add an order field in your imageXgallery table. When you retrieve your images from the table you can order by that column.
While there may be slightly faster and more elegant solutions, exploding, cutting out and gluing together again is a perfectly acceptable way in my opinion.
Edit: Of course, Galen is right. If you have the chance, change the structure.
As Galen said, you need to normalize. Instead of a tuple (row) like ("gallery_id", "photo_id_1, photo_id_2, ...") you will have multiple tuples each having one gallery_id and photo_id. Then by deleting the photo_id from that table will take care of your problem.
If you don't want to change your table structure, it's probably less expensive to do string operations than to convert the strings into an array and back again. Look into using either str_replace() or preg_replace() for that.
If you can change the database layout, I would do the following:
As each gallery can have multiple images and as each image can be in multiple gallery, you have a many-to-many relationship.
So you have 3 tables, the first one to hold the gallery, with a galleryId primary key and additional fields for gallery info (if galleries have names, for instance, a name field), then you have an image table, with an imageId and all the image information, and then you have third table with just two fields, galleryId and imageId.
So if image 5 has to go to gallery 7, you'd enter 7 and 5 into the relationship table.
to get all the images for gallery 7, you'd run something like
SELECT * FROM images i LEFT JOIN galleryImages gi ON gi.imageId = i.imageId WHERE gi.galleryId=7
with galleryImages being the relationship table.
Likewhise, to delete an image from a gallery, just delete the row in the relationship table.
One thing you might want to pay attention to is to check if there are still entries for an image in the relationship table when you remove it from a gallery. or in other words, check if the images is being used in any galleries, if not, remove the entry from the images table as well, otherwhise you might end up with a lot of garbage image entries that aren't even needed anymore.
hope this helps to clear some things up.