Steve Thompson-454462 (5/3/2012)
I think thats fine if you are only storing the role and thats as far as you go with it, so I'm ok with this. If you are going to store additional info regarding the persons role as a student then the student table makes sense.
Yup, I agree (my original post asks whether they are planning on tracking extra student-specific data).
If you need to track data that is applicable across all roles (e.g. a RoleStarted/RoleEnded date) then those columns could be added to the many-to-many link table without adding a specific table for each role.
However, if in your business model you are tracking attributes specific to students, professors, employees, etc., then a table to organize these attributes makes sense.
i would say that you need to think about what will happen in thte future - while this system only really lists the names and addresses of students and employees, it's not unreasonable to say the following
students take classes , employees do not
employees have timesheets, students do not
employees get appraisals
students get grades
if any of the above ever make it into your functionality then a "role" table is (IMHO) not the best way to go - (plus with a role table you might have real issues if you are a student and an employee - as happens at some universities)
without a full understanding of the context of the model and the roadmap it's hard to say what is the correct design
MVDBA