Table one
Id subject class teacher
1 English 1 1
2 Math 1 2
3 SST 1 3
4 Computer 1 1
5 Physics 1 3
6 Chemistry 1 3
Each subject assigned to particular teacher, some subject has same teacher.
Now i want to store values in another table having these fields and other fields as well.
Table Two
id subject teacher
Whereas form only post subject ids, how can i get teacher id against each subject id from Table one and store it in table two?
Your question is very unclear. Are you asking for how to use relational databases and foreign keys? If so I would read up on how a relational database works and that will answer your question. If the question is about how to do this in code then please state that and also post your attempt at it.
What i think you want to do is get the of the subject posted, i.e. query the database :
SELECT subject, teacher FROM table_one WHERE id = 'POSTED_ID'
Then insert the new record into the table two, something like :
INSERT INTO table_two (subject, teacher) VALUES ('subject_value', 'teacher_value')
Hope this helps!
Related
This question already has answers here:
Basics of Foreign Keys in MySQL?
(4 answers)
Closed 3 years ago.
Let's say I have two tables:
mice
id (int) petname (varchar) gender (enum (male, female))
1 spot male
2 rice female
men
id (int) name (varchar) gender (enum (male, female))
1 bob male
2 jane female
3 steve male
The gender enum exists twice. Once for each table. So if I wanted to expand the gender enum with new values, this would mean that I would have to manually edit the enums in several tables. This is suboptimal.
Is there any way to define the enum values once and use them in several tables?
Or perhaps to create a new table named genders and put the genders there, and then during inserts and updates into mice and men, it would only allow the gender column to contain values form the gender table. This check however needs to happen automatically (like with enum column type), so I don't have to execute additional queries first to check if the used gender exists in the gender table, before each update or insert query I want to run, which inserts a value into a gender column in mice or men.
Can this be done with mysql?
You can forget about SQL's enum. Instead, just use VARCHAR(50), etc, and use const in your PHP code to define the enum values.
I seldom use SQL's enum, in most cases, its benefit is less than its complexity。
I want to create a table with two columns - name and courses. So, let's say for the first row, I want to insert John into the name column, and insert maths, English, chemistry into the courses column(the same row as name-John). Is this possible with php/mysql.
You can save 3 rows with name set to John for each of Maths, Chemistry and English.
Just add another column asy 'name_id' which is same for the three rows.
That way, if you want to see this particular John's subjects, you can fetch his subjects SELECT courses FROM student_db WHERE name_id="xx"
That would be a easier way.
If you want a single row for John then
INSERT INTO student_db (name,courses) VALUES ('John','Maths,Chemistry,English')
should work.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have taken it on myself to create a site that allows users to add each other as friends and comment on each others posts. After looking into this I'm not sure exactly how to start. I have a posts and a users table.
My question is how would I relate the databases to
1.Check if user A has sent a friend request to user B?
2.Store a value to indicate that they are friends?
I've browsed around this site before posting but can't seem to understand how to carry this out. Pretty sure I'm just over complicating it. Could anyone explain the concept or how this works?
This could be done with a relational database, and it would be worth reading up on how relational databases work e.g. https://www.youtube.com/watch?v=NvrpuBAMddw
But - to give some pointers, it looks like yor want your relational database to allow for the following functions:
a number of users
a series of posts, by certain users
a number of relationships between users
an ability to verify a relationship before it is confirmed
a series of posts, by certain users
a number of 'sub-post' comments on posts
1) Let's start with the 'friend request' section.
This would need you to have a) a whole load of different users, and b) a load of relationships between those users.
You'd need to represent that in 2 different tables - so create a users table with the following fields:
UserID, name, age, [details, password, address etc etc]
and then a friends table which has these fields:
friendID, userID1, userID2, [date, confirmed]
Your user table might look like this:
UserID, name, age,
1 Fred 18
2 George 24
3 Michael 20
4 Alice 24
5 Sophie 20
6 George 19
Let's say that Michael wants to become friends with Alice and Fred, and Alice wants to befriend Sophie - you'd want to create records in your friends table that looked like this:
FriendID, userID1, userID2,
1 3 (this refers to Michael) 4 (this refers to Alice)
2 3 (this refers to Michael) 1 (this refers to Fred)
3 4 (this refers to Alice) 5 (this refers to Sophie)
So if you then looked for Michael's friends - you'd do a query which looked for:
every record from the friend table where userID1 = Michael's userID.
From the userID2 field, you'd get userID 4 and userID 1
By looking up those userids in the user table, you'd find more details for Alice and Fred.
You should make this query check whether userID1 OR userid2 = the userID you need, so that you get the same results if e.g. the table looked slightly differently:
FriendID, userID1, userID2,
1 3 (this refers to Michael) 4 (this refers to Alice)
2 1 (this refers to Fred) 3 (this refers to Michael)
3 4 (this refers to Alice) 5 (this refers to Sophie)
Otherwise you'd only know about Alice.. but you want to know about Fred too.
2) If you want to confirm a relationship, you could add a 'confirmed' field to the friends table - set it to binary 0 = not confirmed / 1 = confirmed.
When the friendship is requested, you add the record to the table, but when it is confirmed, you would update the 'confirmed' field for that record to 1.
Let's update our friends table accordingly:
FriendID, userID1, userID2, confirmed
1 3 (Michael) 4 (Alice) 0
2 3 (Michael) 1 (Fred) 1
3 4 (Alice) 5 (Sophie) 1
If you want to see all friends that are pending Michael's acceptance, you'd search for:
any records from the friends table where userid1 = 3
AND confirmed = 0 ... which means it hasn't been accepted yet.
This would show that alice hasn't yet been accepted as a friend by Michael.
If you want to see all friends a user had requested but which haven't been accepted you'd look for:
any records from the friends table where userid2 = the user you're looking for
AND confirmed = 0 ... which means it hasn't been accepted yet.
If you want to see all accepted friends, switch 'confirmed' to 1.
3) You also wanted to have posts for each user... so you'll need a posts table with fields for:
postid, userid, date, content
We've already got your user table, so let's say that Michael wanted to post some stuff. The posts table might look like this:
postid, userid, date content
1 3 (Michael) [auto datetime] Hi everyone
2 3 (Michael) [auto datetime] This is my second post
You've now got a relationship between Michael and the posts table. If another user posted something, they'd add another line with a different userid. You can then retrieve all the posts from the posts table where the userid = 3, which is Michael's userid.
4) To add comments on posts you would need a comments table that might look like this:
commentid, postid, userid content
1 1 3 (Michael) Michael is commenting on his own first post...
2 2 4 (Alice) Alice is saying something on Michael's second post
in a school management system, we need to incorporate 3 semester grades for each subject by each student.
after a discussion, i came up with two solutions.
solution 1
create 3 tables for each semester. (gradeSemester1, gradeSemester2, gradeSemester3)
solution 2
create 1 table called, semesterGrades and with a type handle all 3 semesters.
the reason for solution 1 is to stop data duplication. for example, if there is 8 subjects for a student. this can only contain 8 records in a table where as in solution 2 it can contain up to 24 records of a single student.
what will be the best solution when performance is a major concern ? why solution 2 is better ?
You don't want to change the Database structure depending on the data, so creating a new table whenever you need a new semester is bad design.
All you need is one extra table to store the grades. However I would personally not store them in columns, but in rows to be more flexible (maybe some day you want more than the grades of only 3 semesters).
The table would look like this:
ID | StudentID | SemesterID | SubjectID | Grade
Another advantage of this approach is that you know which semester a grade belongs to. If you have 3 columns for the grades, you only know the grades but you have no information about the semester (I'm guessing he could take more than 3 semesters if needed).
Also I would not worry about performance with this approach. You will have to join tables together but with the proper indexes set up that should not be an issue.
Joining tables is way more costly than a single select because in a join you're selecting and THEN pairing to create a single huge table.
Why not Solution 3:
Create 1 table with 3 columns (one for each semester). That's effectively what your join will be doing each time anyway. Is there any reason to keep them separate?
EDIT (explanation):
Unless I'm misunderstanding something...
A single row in this table would relate a student to a subject and could contain three columns (one for each semester grade). Assuming you have a table for students AND another table for subjects. Containing three semester grades in this table would still be normalized.
TABLE
----------------------
student_id
subject_id
semester1grade
semester2grade
semester3grade
Apologies if this is really stupid but I don't have any experience in php and mysql to know how things should be done. I have a customer table in a mysql db and a group table:
customers - ID name email phone group
groups - ID name description
So I need to assign groups to customers if necessary, this can be more than one group to each customer. So e.g. customer 1 is in group 4,5,6
What way should I assign groups in the group column of the customer table. Should I just add the group ID's separated by commas, then just use explode when I need to get the individual ID's out?
Maybe this isn't the right approach at all, could someone enlighten me please. I would appreciate knowing the right way to do this, thanks.
Do not store multiple IDs in one column. This is a denormalization that will make it much harder to query and change your data, as well as hurting performance.
Instead, create a separate CustomerGroup table (with CustomerID and GroupID columns), and have one row per Customer/Group relationship.
Here is an example of tables to show how you should implement this :
Table 1 CONSUMERS:
id name email
1 john john#something.com
2 ray ray#something.com
Table 2 GROUPS :
id group_name description
1 music good music group
2 programming programmers
Table 3 CONSUMERS_GROUPS
consumer_id group_id
1 1
1 2
2 1
Now the table 3 is listing consumers ids which belong to which group id.
This type of relationship is called one to many relation where, one consumer can have many groups. Reverse might also be true where one group can have many consumers. In that case relationship is called many to many
Should I just add the group ID's separated by commas, then just use explode when I need to get the individual ID's out?
No! If you do that then you won't quickly be able to (for example) query for which users there are in a specific group.
Instead use a join table with two columns, each of which has a foriegn key constraint to the corresponding table.
group_id customer_id
4 1
5 1
6 1