I have 40 students and each have enrolled in five courses. Every course tracks attendance: the date on which each student was present. I'm thinking to create a separate table for each student. Is there any efficient way to do this?
Do NOT create a table for each student.
What you should have is a Student table, a Course table, and an Attendance table. The Attendance table should have columns for the student key, the course key, the date, and the status (present, tardy, absent, etc).
This will be far more efficient than using separate tables for each student.
You could write a stored proc that takes a comma-separated list of your student names and builds the tables from that. However, creating 40 tables that are identical except for the name seems really inefficient. SQL can handle large row sets, no problem. Even if you put all of the students into the same table and they had an attendance row for all 365 days of the year (40 students x 5 courses x 365 days) is only 73,000 rows/year; that's nothing for SQL.
Also, if you ever wanted to do any reporting with multiple student tables, you will need to target EVERY table instead of just targeting your one main table and grouping by studentID.
In short, yes you can write a proc that will dynamically create identical tables for each student. Is it a good (read: efficient) idea? Personally, I don't think so. I think you could get way more performance (losing some because of larger searches but gaining some for not having to JOIN any tables) and reporting ability in a much shorter amount of time/work by keeping it all on one table.
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.
I'm setting up a system where for every user (1000+), I want to add a set of values every single day.
Hypotetically:
A system where I can log when Alice and Bob woke up and what they had for dinner on the August 1st 2019 or 2024.
Any suggestions on how to best structure the database tables?
A person table with a primary person ID?
rows: n
A date table with a primary date ID?
rows: m
And a personDate table the person ID and date ID as foreign keys?
rows n x m
I don't think u need a date table unless u want to use it to make specific queries easier. Such as left join against the date to see what days you are missing events. Nevertheless, I would stick to the DATE or DATETIME as the field and avoid making a separate surrogate foreign key. It won't save any space and will potentially perform worse and will be more difficult to use for the developer.
This seems simple and fine to me. I wouldn't worry too much about the performance based upon the number of elements alone. You can insert a billion records with no problem and that implies a very large site.
Just don't insert records if the event didn't happen. In other words you want your database to grow in relation to the real usage. Avoid growth based upon phantom events and you should be okay.
person
person_id
action
action_id
personAction
person_id
action_id
action_datetime
Consider we have one sql table customers
now consider iF we have a table where their are two columns customer_name and orders_name now one customer may have multiple orders (one to many relationship) So we have table where in which we choose customer_name as foriegn key. But now consider we have 100 orders to one customer_name so we have to write same customer_name 100 times. waist of memory.
customer_name,customer_orders table is
so i was thinking is can't we just make table with name of customer_name orders, for examle if we have customer_name bill so we can create a table with name of bill's orders, and write all his orders in it, now we not using any foriegn key,
bill's orders table is
and more tables we can create for other users so how it is possible to delete the table when we delete that customer_name from main table. any idea?
You solve the issue of wasted space by using surrogate keys. Instead of copying a huge alphanumeric field (names) to child tables, you would create an ID of sorts using a more compact data type (byteint, smallint, int, etc.). In the approach you propose where you create a separate table for each customer, you will run into the following issues:
cannot run aggregates across customers, i.e., you cannot simply do a sum, avg, min, etc. for sets of customers slicing the data different ways
SQL will be far more complex with each extra customer added to the queries
your data dictionary is going to grow huge and at some point you will incur major performance issues that are not easy to fix
The point of using a relational database is to allow for users to dynamically slice and dice the data. The method that you are proposing would not be useful for querying.
I am converting a spreadsheet to a database but how do i accommodate multiple values for a field?
This is a database tracking orders with factories.
Import PO# is the unique key. sometimes 1 order will have 0,1,2,3,4 or more customers requiring that we place their price tickets on the product in the factory. every order is different. what's the proper way to accommodate multiple values in 1 field?
Generally, having multiple values in a field is bad database design. Maybe a one to many relationship will work in this scenario.
So you will have an Order table with PO# as the primary key,
Then you will have a OrderDetails table with the PO# as a foriegn key. i.e. it will not be designated as a primary key.
For each row in the Order table you will have a unique PO# that will not repeat across rows.
In the OrderDetails table you will have a customer per row and because the PO# is not a primary key, it can repeat across rows. This will allow you to designate multiple customers per order. Therefore each row will have its own PriceTicketsOrdered field so you can know per customer what the price is.
Note that each customer can repeat across rows in the OrderDetails table as long as its for a different PO# and/or product.
This is the best I can tell you based on the clarity of your question.
Personally, I normally spend time desinging my database on paper or using some drawing software like visio before I start implementing my database in a specific software like MySql pr PostgreSql.
Reading up on ER Diagrams(Entity Relationship diagrams) might help you.
You should also read up on Database normalization. Probably you should read up on database normalization first.
here is a link that might help:
http://code.tutsplus.com/articles/sql-for-beginners-part-3-database-relationships--net-8561
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".