Clustered indexes are not a good choice for the following attributes:
* Columns that undergo frequent changes
This causes in the whole row to move, because the Database Engine must keep the data values of a row in physical order
https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

Смущает меня эта формулировка: ну ок, в следующий раз, когда будет выполняться alter index reorganize, строка физически переместится на диске, если новое значение ключа   отличается по порядку от старого. Какое отношение к этому имеет must keep the data values of a row in physical order, физический порядок данных в конкретной строке? (так понимаю, речь идёт о порядке столбцов в таблице, раз речь о строке в единственном числе)

Здесь же речь про кластерный индекс - если изменяется его значение - строка физически переносится в другое место

"Кластеризованные индексы — не лучший выбор для следующих атрибутов:

столбцов, которые подвергаются частым изменениям;

Изменения вызывают перемещение целых строк, потому что компонент Компонент Database Engine должен сохранять значения данных строки в физическом порядке. " - есть же документиция на русском языке
https://docs.microsoft.com/ru-ru/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

меня тут смущает то, что идёт речь о строке в единственном числе)

Вы имеете ввиду обновление целого диапазона индекса?

Что тебя смущает - не понятно. Кластерный индекс должен на таблице быть один, и это должен быть первичный ключь.
Первичный ключ не меняют, поля не меняют никогда.
Собственно, это и написано

Это СУБД должна , то есть у неё нет другого выхода просто, хранить строки физически упорядоченными.

Тут ты проreorganize что-то загнул совсем не в тему. Он тут ни при чем

>because the Database Engine must keep the data values of a row in physical order
>потому что компонент Компонент Database Engine должен сохранять значения данных строки в физическом порядке

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

Столбцы в строке не меняются, перемещается сама строка - затратная операция, поэтому и не рекомендуемая

по-моему, никак не связано. Ну вот, на место старых данных в столбце (который входит в ключ) в конкретной строке ты записал другие данные. С чего бы это влияло на другие столбцы в той же строке 🤷🏻‍♂️

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

Безусловно. Но в современном SQL server - 90% кластер - первичный ключ- автоинкремент

Тут согласен. Но есть, например, Аксапта )

Кажется у тебя с английским просто проблемы...

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

и да и нет🧐
логически должны храниться в порядке, который определяется кластеризованным индексом. Физический порядок хранения строк, по факту, может отличаться

Добрый вечер, можете, пожалуйста, помочь со структурой?

Есть табличка юзеров, студентов и преподавателей. Юзер одновременно может быть либо студентом, либо преподавателем, при этом у преподавателей есть список предметов которые они могут вести, в отдельной табличке со связью многие ко многим, студенты объединены в группы со связью один ко многим, и есть расписание, где хранится номер группы, что за предмет и преподаватель который ведёт то или иное занятие. Добавлять опциональные связи 1 к 1 между сущностью юзера и преподавателя, юзера и студента кажется не лучшим выходом. Как в таком случае лучше поступить?

Не может

Кластерный индекс на то и кластерный, что порядок задаёт, физически

Используй отношение подкатегории, она же наследование классов.