Это связь от родителя к ребенку 1 к 0..1

Внутри страницы они хранятся в порядке ключа. Ещё минус изменяемого кластерногл ключа — в лог это пишется как удаление строки и добавление новой. То есть не только изменённые колонки, а вся строка полностью.

это распространённое заблуждение)

In addition, do not suppose that the data is physically sorted ... This way, you get some internal fragmentation, which you cannot get in a heap. In addition, the new page (or new uniform extent for a large table) can be reserved
anywhere in a data file. Physical order of pages and extents of a clustered table do not need
to correspond to the logical order. If pages are physically out of order, then the clustered
table is logically fragmented. This is also known as external fragmentation. External fragmentation
can slow down full or partial scans in logical order

(70-461)

When created, a clustered index is maintained logically rather than physically ...
Only the logical order of a clustered index is maintained after it’s created
(Delaney, Sql Server 2012 Internals)

Нет

Что за цитаты ты все время даёшь, откуда ты взял это?

я же в скобках указываю источник)

эти двое пацанов

В курсе, как строки на странице хранятся? Физический порядок никто не гарантирует, главное чтобы указатели в конце страницы были в нужной последовательности. Порядок экстентов в файле на диске - тоже без гарантий. Ведь есть IAM и двусвязный список индекса.

Все зависит от ваших задач, не вижу ничего крамольного в добавлении внешних ключей в таблицы преподавателей и студентов

Сам делал похоже приложение (на Джанго), более интересен вопрос как вы само расписание формируете и храните?

В данном контексте что подразумевается под словом "указатели"?

Проект в состоянии зародыша, так что пока табличка расписания просто имеет связи с предметом, группой и учителем. Один предмет много записей в расписании, одна группа много записей в расписании, один учитель много записей в расписании. Пока не вижу необходимости в более сложных связях, вроде и так хватает.

Вы имеете ввиду что можно добавить в таблицы преподавателей и студентов внешние ключи, но при этом не добавлять их в табличку юзера?

Там очень много ньюансов у вас вылезет (черные нечётные недели, деление групп на подгруппы, лабораторные занятия которые проводятся одновременно в одной аудитории разными преподавателями для разных групп, зачётная неделя, экзамены, гос экзамены, лекции для всего потока и определенных групп, замена преподавателей, удаленнве занятия по zoom или другим конференц приложениям и так далее)

Вопрос не понял

Это проект для себя, возможно для гитхаба, и он больше ориентирован на фронтенд и React, мне за это никто не платит так что структуру я не хотел бы сильно перемудрять учитывая абсолютно все нюансы, так как в таком случае на построение структуры БД уйдет намного больше чем требует цель проекта.

Просто стокнулся с необходимостью, грубо говоря, иметь эдакую опциональную связь таблички юзеров и студентов\преподавателей, потому-что юзер он или студент, или преподаватель.

Пока, как быстрое решение, мне в голову пришло что-то вроде:

Но я не уверен насколько оно верное, потому-что одновременно пользователь может быть либо студентом, либо преподавателем, поэтому желательно как-то ограничить возможность записей из двух таблиц указывать на одного юзера.

Если сделать так и проверять не заполнено ли поле TeacherId, когда юзеру присваивается StudentId, и наоборот, и при этом запрещать заполнять одно поле, если другое заполнено, то выходит что одно из этих полей будет пустым в 100% случаев, и это как-то сомнительно выглядит.

вы вообще сами себе противоречите.
вам расписали сложности->ваш ответ , я не буду усложнять и вообще я художник, минимализм наше все.
сделали 1-й вариант, и тут до вас начало доходить, что все не так просто.

учитель может проходить курс временно, прервать его.
т.е. на 01.01 он преподаватель и студент
на  02.01 он преподаватель
а может уволиться и записаться на курсы вновь
т.е. 03.01 он студент
:)

и это только пена, подводная часть айсберга вам все еще не очевидна.

оу майн