Всем привет. как принято хранить в базе сущности, у которых в

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

Wut?

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

Нельзя. Потому что это получается нереляционная база. А вот в какой-нибудь MongoDB - пожалуйста

Хорошо, а как мне тогда это хранить? Обращаясь к примеру с пользователями: На каком-нибудь сишарпе, я бы сделал класс пользователя (логин и пароль) и от него уже бы наследовал условно класс студента (ФИО, номер группы) и класс преподавателя (ФИО, преподаваемые дисциплины, курируемые группы и тд) - это как раз были бы две роли. Как мне подобное в бд хранить-то? Насколько я знаю, наследование там не такое как в ООП. Можно создать единую таблицу для хранения всех ролей вместе, но тогда там половина столбцов будет заполнена null

Это будут отдельные таблицы. Человек с айдишкой Преподаватель с айдишкой и внешней ссылкой на айдишку человека и т.д. Это вообще нужно основы проектирования реляционных БД объяснять

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

изучить про третью нормальную форму))))

Это и для шарпа плохо звучит, потому что пользователь не определяется данными авторизации

Такое наследованием можно делать. Но это всё будет статично в рантайме. Если надо динамично - EAV.

Вот наследование и используй.

В БД в общем-то вообще нет наследования. Ну, и половина null, ну и что. Впрочем, надо сказать, что в данном случае вероятно имеет смысл создавать "шырокие" таблицы, в которых запись в "преподаватель" ссылается на "пользователь" и запись в "студент" ссылается на "пользователь", отношэнием один-к-одинилиноль.

Ну, есть... Пять видов реализации...