>>Coming to this thread late, but I have done a lot of school registration stuff so I offer this general design observation: there should be an entity which is a registration i.e. the registration of a particular student for a particular class. In data this is represented as a join table which hold as FKs the pk of the student and the pk of the course ( I finally learned to avoid the reserved word "class" in school software < g > ) One student will have many courses and one course will have many students. Views that use this pivot table will be able to get either situation. The pivot table is also a very good place to store the grade.
>
>Thank Charles. Makes sense.
>
>What would you do in the case of an elementary school where all classes (oops, courses) are taught by the main teacher to all students in a group?
>
>Alex

I think I would still use the course/student pivot table for grades and have the teacher linked to the course. That way if music or something was taught by another teacher or if some students received partial day instruction in some special needs or gifted program that would be reflected. I figure teacher links to course and the pivot table links the course to the student.

I also tend to keep student's grad year in their record and flag each student as active/withdrawn/graduated/expelled/transfered. That way when they graduate their records are still in the system for transcripts but I can have the working view show only active students.

Also, courses have one record for every semester, trimester or quarter and the course record contains the school year as well. That way the pk of the course that is used in the pivot table identifies the time period. Easy to generate the new set of records for courses and adjust them. But different teacher may teach 2nd semester etc. Makes report cards easy.

System has setup info that hangs off the application object that has current quarter, school year etc. for default values as new records are created.