for example,access example db, every student record have a nested table about guardians.
http://img101.imageshack.us/img101/9881/53882937.jpg
No. Something like that is almost always done as a single mapping table for all students, with a foreign key column pointing to the student table to specify which student a particular row relates to.
You then just filter the table to match a given student, and present that list without a student column, in the UI. It looks like a separate table to the user, but that's not actually how it's stored.
(If you did create a separate guardians table for each student, you'd make it impossible to do queries like ‘find students for a particular guardian’.)
Related
I am going to write some code to retrieve and add to/remove from a student's hours that they have signed up for. For example...
student 1:
October 20th:
12am
4pm
7pm
October 21st:
8pm
student 2
October 19th
1pm
6pm
I'm trying to wrap my head around how to create this type of table setup on phpmyadmin with each student having a dynamic number of hours, and different times, and different days. I am new to mysql management, am vaguely familiar with joins and stuff, and am just now starting to expand my database to more complex things like this. What I have learned so far is that enums is NOT where I want to go. Just unsure of a starting point...
What is a good strategy for doing something like this?
Thank you,
you need to create many to many relation
first i try to explain it simple and fast:
1- you need to make a table for hours, each hours have 1 row.
2- i guess you already have a student table
3- now you need a table that contain only 2 column, first column is hours table id, second column is student id.
at the end you simply need to execute select command like this:
select * from StudentHours Table where student-id = 1;
Detailed Information:
Relational database systems usually don't allow you to implement a direct many-to-many relationship between two tables. Consider the example of keeping track of invoices. If there were many invoices with the same invoice number and one of your customers inquired about that invoice number, you wouldn't know which number they were referring to. This is one reason for assigning a unique value to each invoice.
To avoid this problem, you can break the many-to-many relationship into two one-to-many relationships by using a third table, called a join table. Each record in a join table includes a match field that contains the value of the primary keys of the two tables it joins. (In the join table, these match fields are foreign keys.) These foreign key fields are populated with data as records in the join table are created from either table it joins.
A typical example of a many-to many relationship is one between students and classes. A student can register for many classes, and a class can include many students.
The following example includes a Students table, which contains a record for each student, and a Classes table, which contains a record for each class. A join table, Enrollments, creates two one-to-many relationships—one between each of the two tables.
Let's say there is a database with two tables: one customer table and one country table. Each customer row contains (among other things) a countryId foreign key. Let's also assume that we are populating the database from a data file (i.e., it is not an operator that is selecting a country from a UI).
What is the best practice for this?
Should one query the database first and get all ID's for all countries, and then just supply the (now known) country id's in the insert query? This is not a problem for my 'country' example, but what if there is a large number of records in the table that is being referred?
Or should the insert query use a sub query to get the country id based on the country name? If so, what if the record for the country does not exist yet and has to be added?
Or another approach? Or does it depend? :)
I would suggest using a join in your insert query to get the country id based on the country name. However, I don't know if that's something possible with every SGBD and you don't give more precision on the one you're using.
I know it's possible to have n amount of columns, but is it proper mysql "coding standard"?
Here is what I'm doing:
I am a table student which includes all the students info including testScores:
student
-------
studId
name
age
gender
testId
Instead of putting each individual test answer within the student table, I made a separate table called testAnswers that will hold each students test results:
testAnswers
-----------
testId
ques1
ques2
.
.
.
quesN
Each entry in the testAnswers table corresponds to a specific student in the table student.
Of course, there will be an admin that will be able to add questions and remove questions as each year the test questions may change. So, if the admin were to remove an answer, than that means one of the columns would be removed.
Just to reiterate myself, I know this is possible to edit and remove columns in a table in mysql, but is good "coding standard"?
The answer is a simple and clear: No. That's just not how you should do it except for very few corner cases.
The usual way to approach this is to normalize your database. Normalization follows a standard procedure that (among other things) avoids having a table with columns names ques1, ques2, ques3 ....
This process will lead you to a database with three tables:
students - id, name, and other stuff that applies to one student each
questions - id and question text for each question
answers - this is a N:M relation between students: student_id, question_id, answer_value
Use two tables!
What you are describing is a one to many relationship as there can be one student to many test scores. You would need to have some id as a foreign key to the student_id and put this id in the testAnswers table. You can then set constraints, which tell the database how to handle removal of data.
As one commenter has mentioned, using one table would result in breaking 1nf or first normal form which basically says that you cannot have multiple values for a single column given a particular record - You can't have multiple test scores for the same user in a given table, instead break the data up into two tables.
...of course 2 tables, also could use 3, just remember to insert a studId column also in the testAnswers table (with REFERENCE to the student table) and an INNER JOIN testAnswers ON student.studId=testAnswers.studId at the SELECT query (to read the data).
I have 2 tables.
First table is called professions, and those are indexed by ID. So each profession now has a unique ID associated with it.
My second table is called contacts, and in there I have a profession field that right now only hold the ID that a certain profession is associated with.
My problem is that what if I have a contact that has more than one profession associated with it.
What would be the best way to query the table and ways to store the professions of a contact. I didn't want to do is create a field to just store a 0 or 1 int for each profession I have. The reason is because I want to dynamically grow the professions table and have the numbers reflect any dynamic changes on my site when I query.
You have a many-to-many relationship. To implement that in MySQL you should use a linking table. So professions and contacts should have an id in each table, but no foreign keys, and you create a new table called profession_contact_links or something, containing its own id, and profession_id and contact_id, which are both foreign keys to the respective tables. Then you can have many contacts linked with each profession, and many professions linked with each contact. To connect the two main tables together in a select you will need two joins, and what they are will depend on what exactly you want to select.
The standard solution to this modelling issue is called a link table.
Basically it is a table that contains the ids of the two tables that are linked, so you would have a link table with to columns and a primary key that is both of those columns:
(profession_id, contact_id)
or the other order... doesn't matter that much, but the order can affect performance, the key you will be searching on most often is the one you want first.
You then use either SELECT ... IN (...) or SELECT ... JOIN ... to query the data that you are after.
Depending on what you want and how you want to find it, i'd suggest rlike or in
SELECT ... FROM <table> WHERE <column name> RLIKE "^id1|id2|id3$"
This will find any cell that contains any of those three terms
or use
SELECT ... FROM <table> Where <column name> IN ('id1','id2','id3')
this will find any cell that is equals to one of those three.
I am not really experienced with databases but I have a little problem. I am trying to create a database that stores the courses being taken by students and lecturers so I created three tables. In the lecturer and student tables, the field courses represent a comma separated list of the courses taken by either the lecturer or the student.
Something like this:
Lecturer - Courses - "1,2"
Student - Courses - "1,2,3"
Courses - 1 - "Bio"
The problem however is that when I want to show a list of student based on their courses, I have to search all the students and the courses and search again to check whether the csv list has the specified course (which seems a bit redundant). Is there another way I can achieve this goal, say by relating/referencing the indexes or something? Thanks
Create two new tables:
student_courses(int student_id, int course_id)
lecturer_courses(int lecturer_id, int course_id)
You can now create individual rows for each course a student is taking and each course a lecturer is teaching, assuming that you want to track delivery of a course separate from taking the course. You can then write queries against those tables using course id when you want to do course related analysis.
the field courses represent a comma separated list of the courses taken by either the lecturer or the student
A field that contains a csv list is breaking First Normal Form (1NF) and has all sorts of problems, including performance. Breaking out this field into a separate Junction Table {StudentID, CourseID} is what you should do.
Instead of storing a text like "1,2,3", store several rows:
1 row for every student in a table named "students"
1 row for every course in a table named "courses"
Then create another table named "student_in_course" which has 1 row for every combination.
Then do the same for "lecturer_in_course".