I'm unsure how to link my tables:
Users(registration details of users),
Personal (personal details of users),
Academic (academic details of users),
Language (language details of users),
Thesis (Thesis details of users),
Referees (Referee details of users),
Addresses (Address details of users)
Should I have an 'id' field in each of the tables so I can join them all? Plus a primary key of of e.g. Academic_ID. Which would I set as auto inc?
Once the users registers, my system should link information from the users table to all other information they enter for the other tables.
I hope this makes sense
thanks
Add a field named "user_id" to your Users table. Then, in each table you wish to join to Users add a field with the same name.
This way, you could make a query like:
select * from Users, Personnal
where Users.user_id = Personnal.user_id
which would join your results the way you want. About your second question, yes you can/should add a unique autoincrement field like personnal_id and so on. Good practice and makes you record unique.
I tend to do an id field as the primary key (autoincrement), then you can do a unique key on lets say user_id (in each table) and then u can use user_id to link the tables.
Related
I'm creating a website and users can add friends. I want them to be able to see their personal friends on a page.
For exemple:
John add user Tim and Bill.
When John goes on his friends list page, I want him to be able to see that he has Tim and Bill. How do I do that? Is that even possible? Do I need more than one table? If so, does every user has to have his own friendsList table?
Yes this is possible, you do this by querying the information from the database, the answer for if you need multiple tables etc all depends on your current table structure but at the very least you need to have some way of referencing that a Person 'John' has friends, wether thats just a 'friendID' in the same 'Person' table, or another means of doing so. then it is just a matter of querying the data correctly to return what you want and bind to the websites fields :D
One way of defining the structure is the following:
Person
PersonId
Name
<other person fields>
Relationship
RelationshipId
Name --> allow to define multiple relation types like Friendship, Follows etc.
Relationship
RelationshipId
Person1Id --> FK to Person
Person2Id --> FK to Person
RelationshipTypeId --> FK Relationship
Basically, you use an n:n between Persons (anyone can have any number of friends) and also allow for other types of relationships.
Assuming you already have a table of users, one approach would be to create a "friends" table which relates users to other users.
CREATE TABLE friends (
`user_id` INT NOT NULL,
`friend_id` INT NOT NULL
);
Both user_id and friend_id would have foreign key constraints on your existing users table (so that you guarantee an id must exist in your user table in order for it to exist in the friends table as either a user_id or friend_id).
You can then link your user table on users.id = friends.friend_id to get the friend's info.
Here is a SQL Fiddle Demo showing how this works.
You should consider using an ON DELETE CASCADE constraint on the friends table, so that if a user is deleted from the user table, the associated records in the friends table are also deleted.
Im new to building databases and have seen both examples of using and ID field or changing the field to a related name such as user_id is this just preference?
I guess it's a matter of personal taste. What I've come to find useful is to name the ID column id, but in tables where this is a foreign key, name it table_id.
For example, the ID column in the users table could be named id, but the foreign key in the table that assigns user rights to users it would be users_id to make clear that this is a reference to the users table.
I have a users database and a comments database on a website, and I want to give each user the ability to have a list of favorite comments, and I don't know exactly how to implement this.
Should I create a new table for each user containing the IDs of his/hers favorite comments or is there a better approach?
A common, normalized approach would be a many to many relationship.
The schema for such a table, at a minimum, would be:
user_id
comment_id
Where user_id and comment_id are foreign keys to the users and comments table, respectively.
I would use three tables :
The users table, containing every users, including their personal informations, etc ;
The comments table, containing every comments ;
The favorites table, containing the id of the row, the id of the user and the id of the comment.
I did not name each table well, you should think more about the tables' names (e.g: favorites is a bad name).
I had to implement the following into my database:
The activities that users engage in. Each activity can have a name with up to 80 characters, and only distinct activities should be stored. That is, if two different users like “Swimming”, then the activity “Swimming” should only be stored once as a string.
Which activities each individual user engages in. Note that a user can have more than one hobby!
So I have to implement tables for this purpose and I must also make any modifications to existing tables if and as required and implement any keys and foreign key relationships needed.
All this must be stored with minimal amount of storage, i.e., you must choose the appropriate data types from the MySQL manual. You may assume that new activities will be added frequently, that activities will almost never be removed, and that the total number of distinct activities may reach 100,000.
So I already have a 'User' table with 'user_id' as my primary key.
MY SOLUTION TO THIS:
Create a table called 'Activities' and have 'activity_id' as PK (mediumint(5) ) and 'activity' as storing hobbies (varchar(80)) then I can create another table called 'Link' and use the 'user_id' FK from user table and the 'activity_id' FK from the 'Activities' table to show user with the activities that they like to do.
Is my approach to this question right? Is there another way I can do this to make it more efficient?
How would I show if one user pursues more than one activity in the foreign key table 'Link'?
Your idea is the correct, and only(?) way.. it's called a many to many relationship.
Just to reiterate what you're proposing is that you'll have a user table, and this will have a userid, then an activity table with an activityid.
To form the relationship you'll have a 3rd table, which for performance sake doesn't require a primary key however you should index both columns (userid and activityid)
In your logic when someone enters an activity name, pull all records from the activity table, check whether entered value exists, if not add to table and get back the new activityid and then add an entry to the user_activity table linking the activityid to the userid.
If it already exists just add an entry linking that activity id to the userid.
So your approach is right, the final question just indicates you should google for 'many to many' relationships for some more info if needed.
I want two tables to share a primary auto incrementing id, is this possible? how do i do this? is their anything i need to consider?
the reasons i am doing this, is because it is a better solution than adding groups column to the users table, and also better than creating a completly seperate groups table, because if they share a primary key, i can use the existing posts table for both groups and users. instead of having to create a two distinct posts tables, (group_posts table for group posts. and a user_posts table for user posts.)
existing users table is
id(primary, ai)
username
password
email
my groups table that i want to link to my users table with a shared ai primary key
id(primary, ai, linked to users table id)
group_name
created_by
creation_date
etc.
You should make you schema clearer by doing the following:
Create a table (e.g. people)
id, primary key, auto-increment
type, tells you if it's a user or a group
Make users and groups primary keys foreign keys on people
Insert records in people
Obtain the ID that was assigned using LAST_INSERT_ID()
Insert in users or groups appropriately, using the ID obtained above
Then you'd reference "people", and not "users" or "groups" in your posts table and so on.
Conceptually, thinking of it in an OO way, it means users and groups both extend people.