For clarification, the indication of Students above, as being 'bad' should not be misinterpreted as a bad choice for an actual table name - if a table named Students fits the requirements of your solution. The indication is there because the storage of an actual person who happens to be a Student at the time, should be within a general People table and identified via the data itself (e.g. using either another field as a tag or a join table structure to associate that person as being such a student). A student today is not always a student tomorrow, but they're always a person.

Notice how

Schedule ยป People::id

will be much easier to read within calculation code as opposed to

People__Class Students::tk_student_id