I have a table for the users on my site. The table consists of the the columns
user_id, fname, lname, email, password, interest1, interest2, interest3, interest4,
interest5
Now, It's turning out to not be so practical to store the interests individually like so. What is a better way to do this. A way that keeps it easy to edit/access user interests?
Thanks.
Database normalization does what you want.
You'd create a new interests table with structure like this:
interest user_id
"skiing" 1
"programming" 4
etc...
Then, you can get all the interests for a given user with a query like this:
SELECT `interest` FROM `interests` WHERE `user_id` = :my_user_id;
You have a many-to-many relationship between users and interests. Create a seaparte table of interests and introduce a junction table to link users with their interests.
Create a new table named interests with columns user_id and interest.
Serialize them. This way you can store zero to as many interests you they want and when you unserialize them you can maintain the same data structure (i.e. array or object) that you created them with.
Related
I have a table called user_thoughts. The table has many columns, one of them being favourited_by.
A thought may be favourited by many different users, but I don't want to create a new row stating that this thought id has been favourited by this user.
I would rather have it that it stores multiple username's in one field. So favourited_by for example can hold data like this:
Alice, Fred, Freddy, Conor ....
All in one single row. I have tried messing around with the data types on phpMyAdmin but cannot figure out how the field can hold multiple data.
What you're asking is the wrong way to do this. You should not serialize the favorites data into a text field for either the user table or the thought table. This destroys the whole purpose of using a relational database like MySQL.
The right way to do this: create a cross-reference table between the user table and the thought table. This utilizes a many-to-many table to store a list of favorites using the primary keys of a thought row and a user row.
Your new favorite table:
CREATE TABLE IF NOT EXISTS `favorite` (
`id` int NOT NULL AUTO_INCREMENT,
`user_id` int NOT NULL,
`thought_id` int NOT NULL,
PRIMARY KEY (`id`)
);
What this does is take the id from the user table and store it in favorite.user_id, then stores the id from the thought table in favorite.thought_id.
To add a new favorite for the user with the id of 123, for the thought with id 456:
INSERT INTO favorite (user_id, thought_id) VALUES ('123', '456');
Get the users that have marked the thought with id 456 as their favorite (using a JOIN):
SELECT u.* FROM favorite AS f
JOIN user AS u ON u.id = f.user_id
WHERE f.thought_id = 456;
And similar to the last query, get the favorite thoughts for the user with id 123:
SELECT t.* FROM favorite AS f
JOIN thought AS t ON t.id = f.thought_id
WHERE f.user_id = 123;
The ideal way to handle this is to map it to another table, however you can just store it as json.
MySQL 5.7 even includes JSON as a data type allowing easier filtering and manipulation.
https://dev.mysql.com/doc/refman/5.7/en/json.html
You can put json into any text field however if you don't need to search it, etc.
Okay so im new to databases, and have created a site with a users table, and i also hace a list table, where suers can insert list items, however when they log in everyones list is appearing, how can i link the user table to the lists table, is it creating the same field in each one and using a foreign key? Sorry I am very new to this. Appreciate any help
I think you can just use user_id on both tables to fix this. Let me give an example:
Table A (user_id, username, password)
Table B (list_item_id, user_id , any_other_attribute)
When you design your tables like this a simple sql call will do what you need like:
SELECT 'list_item_id','any_other_attribute' FROM Table B Where user_id=$user_id
Where $user_id is the user_id of the one's who loginned your system.
Also by your question, i suggest you to read about these : 'sessions' , 'sql queries' , 'generating sql query results' on your choice of programming language.
It calls MANY MANY relationnship. There mus be 1 table with fields user_id and field_id that will join this 2 tables
in MySQL, I have a row for each user, with a column that contains friends names separated by \n.
eg.
Friend1
Friend2
Friend3
I'd like to be able to quickly search all the users where the Friends field contains Friend2.
I've found FIND_IN_SET but that only works for commas and the data can contains commas and foreign characters.
Obviously searching with regular expressions and the such will be slow. I'm new to the whole cross referencing so I'd love some help on the best way to structure the data so that it can be found quickly.
Thanks in advance.
Edit: Ok, I forgot to mention a point that the data is coming from a
game where friends names are stored locally and there are no links to
another users ID. Thus the strings. Every time they connect I am given
a dump of their friends names which I use in the background to help match games.
The most commonly used structure for this kind of data is usually adding an extra table. I.e.
user
id,
name
email,
e.t.c.
user_friend
user_id
friend_id
Querying this is a matter of querying the tables. I.e.
List all of a users friends names:
SELECT friend_id
FROM user_friend
WHERE user_id = :theUser
Edit: Regarding OPs edit. Just storing the names is possible too. In this case the table structure would become:
user_friend
user_id
friend_name
and the query:
SELECT friend_name
FROM user_friend
WHERE user_id = :theUser
Why are you keeping friend names as text? This will be inefficient to edit uf say a user removes a friend or changes their name. That's another thing, you should store friend names by some auto_increment id key in your database. It's much faster to search for an integer than a string, especially in a very large database. You should set up a friends table which is like
Column 1: connectionid auto_increment key
Column 2: user1id int
Column 3: user2id int
Column 4: date added date
ect...
Then you can search the connection table above for all rows where user is user1id or user2id and get a list of the other users from that.
My database hasn't been filled yet so I can easily change the format and structure in which the data will be stored.
Yes, you need to normalize your database a bit. With current structure, your searches will be quite slow and consume more space.
Check out this wiki for detailed help on normalization.
You can have the friends table and users table separate and link them both by either foreign key constraint or inner joins.
The structure would be:
Users table
id: AUTO_INCRMENT PK
name
other columns
Friends table
id: AUTO_INCREMENT(not required, but good for partitioning)
UserID:
FriendsID
DateAdded
OtherInfo if required.
Well I'm trying for last 5 days to create simple register, confirm, login PHP script, which is for assignment at UNI, but thing which I'm trying for last 5 days and it's not working is adding friends into friend list. Kid a like Facebook but much much simpler, it's for Android game we got as group assignment.
I have one TABLE users where I have fields ID, username, password, email, friends.
Into field friends I would like to save multiple values as ID's of your friends. To retrieve in game some of user information.
This db and tables are on MySQL and INSERT or UPDATE are not working for me, INSERT is creating new record and can't insert only to one column of existing record and UPDATE can't just insert value but will delete old one and insert new one in.
Seeing as this is a many-to-many relation (if I'm correct) so it'd be smart to create a seperate table that records this.
Table: Friends
userID
userID2 (or friendID)
Which you can fill.
For more info: http://www.singingeels.com/Articles/Understanding_SQL_Many_to_Many_Relationships.aspx
Normally you would add a freinds table with the fields:
user_id
friend_id
where both fields are references to the user tables id field.
If you - for some reason - need it to be a field in user table serialize the id values and save them there.
ATTENTION: you won't be able to easily join the tables and there is no automated possibility to keep integrity. If a user is deleted none of the references to this user in friends field will be deleted. This would all be possibile with the secondary friends table and foreign keys.
What you've described here is a many-to-many relationship between people and their friends. The canonical way do implement this in a relational database is to use a pivot table in which each row represents a "friendship" between two people. You'd have two fields to hold the IDs:
users table:
id, name, email, etc.
friendships table:
user_id_1, user_id_2
Then if user 1 is friends with user 2 and user 3, you'd have records (1,2) and (1,3) in the friendships table. You can treat these as reciprocal relationships if you like, or you can require a (2,1) record to denote that user 2 is also friends with user 1.
So I have a database with a few tables.
The first table contains the user ID, first name and last name.
The second table contains the user ID, interest ID, and interest rating.
There is another table that has all of the interest ID's.
For every interest ID (even when new ones are added), I need to make sure that each user has an entry for that interest ID (even if its blank, or has defaults).
Will foreign keys help with this scenario? or will I need to use PHP to update each and every record when I add a new key?
Foreign keys are a kind of constraint, so they can only fail when you attempt to add records.
You can accomplish what you are describing with a trigger. I don't know the MySql syntax, but in SQL Server it would look something like this:
CREATE TRIGGER TR_ensure_user_interest ON interest FOR INSERT, UPDATE AS
BEGIN
INSERT user_interest (user_id, interest_id)
SELECT user_id, interest_id
FROM inserted
,user
EXCEPT (SELECT user_id, interest_id)
END
Note that this is a rather inefficient approach, but it should cover many of the cases you're concerned about.
UPDATE: I agree with the others who have observed the design "smell" here. If you can accomplish the required result using JOIN queries, that would be a much more efficient solution. However, I was trying to answer the question actually asked. (Plus, I have been in this situation, where physical records are helpful to other database users who are not adept at compound queries.)
For every interest ID (even when new
ones are added), I need to make sure
that each user has an entry for that
interest ID (even if its blank, or has
defaults).
It sounds like you need an OUTER JOIN (either LEFT or RIGHT) in one of your queries instead.
For example, if you wanted to get the level of interest a particular person has for each interest:
Assuming your tables look like this:
users:
user_id PK
user
user_interests:
user_id PK FK
interest_id PK FK
interest_level
interests:
interest_id PK
interest
SELECT i.interest, ui.interest_level
FROM interests i
INNER JOIN user_interests ui USING (interest_id)
LEFT JOIN users u USING (user_id)
WHERE user_id = ?
? is a placeholder.
Note that ui.interest_level will be null for interests with no data.
It sounds like you are forcing your physical design to mirror your logical design too tightly.
Maybe it would be a good idea to rethink exactly why you need to insert a row for every user in the physical table. Couldn't you just write your queries to assume the default value for an interestID if there isn't an associated interestID for a given user?
"Will foreign keys help with this scenario?"
No.
Your constraint is a sort of "completeness" constraint. It implies that for each new Interest added, there must be as many rows added to the USER_INTEREST table as there are users.
No SQL system is able to enforce that for you. It's up to you to enforce it through code.