0

I have two entities, students and tutors. A tutor should be able to submit their grade in a course. A student should be able to set "tutor requirements", i.e. set what courses they want their tutor to have completed.

The courses to choose from will be the same for both the student and the tutor.

My current solution is based on this answer: https://stackoverflow.com/a/18457476/13498210. (See my ER diagram aswell).

enter image description here

Is this solution considered bad practice? I feel like it's unnecessary to use 3 tables.

Another possible solution might be to include every single course as a column in both the Tutor_Courses and Student_Tutor_Requirements, however this solution would require me to update both tables when I add a course and there will be a lot of null values.

hampani
  • 129
  • 11
  • 4
    I feel as if this is a good normalized approach. Courses for both students and teachers are in separate objects. Those tables also have distinct purposes - one for teachers grades and another for student's teacher preferences. Im not a fan of trying to combine these. One is an actual real thing (a teacher is grading a course) and the other is a preference which may or may not be a real thing. Combining these two ideas is asking for problems and you will most certainly be forced to writing bad code to accommodate trying to make something reusable/"flexible." – Doug Coats Jul 16 '21 at 22:47
  • Your first sentence is false: you have five, not two entities: tutors (but you've no table for them -- presumably that's where one of the dangling lines go off to); students (but you've no table for them either -- presumably the other dangling line); courses; tutor course-attendances; student course-requirements. A course or course-attendance might be more abstract/virtual/spread out in time than something you can kick (like a tutor); that doesn't stop it being an entity of interest in the application; and certainly doesn't stop it being something you should model with a table. – AntC Jul 17 '21 at 12:23
  • In real-life applications, over half the tables represent such abstract entities: orders, commitments, monies owing, ... Can't comment on whether your model is 'best practice' without seeing more of the business requirements; but as a rule of thumb, newbs always underestimate the number of tables/extent of normalisation they should go to. – AntC Jul 17 '21 at 12:24

0 Answers0