scymaksскажем у пользователя студента нет логина, а у администртора на есть?Если пишется БД - то у любого пользователя есть логин. Хотя бы - Guest. И нужно просто понимать, что "пустой" логин (даже если вы додумаетесь использовать такое) - это тоже информация...


Далее, по предыдущему посту:

Если вы действительно желаете иметь всяких там методистов и преподавателей, а права привязывать именно к типу пользователя, то строим примерно так:

Есть таблица Users (здесь прописаны все пользователи), в ней поля
id
name
..другие поля

Есть таблица Types (здесь прописаны возможные типы пользователей (Методист и т.п.), они же в вашем понимании - "роли"), в ней поля
id
name
..другие поля

Есть таблица UsersTypes (здесь прописаны роли конкретных пользователей - зачем? затем, что один пользователь может иметь и несколько ролей), в ней поля
idUser (<->Users.Id)
idType (<->Types.Id)

Есть таблица Rights (здесь прописаны права на действия в программе),
id
name
..другие поля

Есть таблица RightsTypes (здесь прописаны соответствия между типами (ролями) и правами пользователей), в ней поля
idUserType (<-> UserTypes.Id)
idRight (<-> Rights.Id)

Когда вы создаете/модифицируете пользователя - вы прописываете его самого в Users, а его возможные "роли" - в UsersTypes. Когда вы создаете/модифицируете "роль" - вы прописываете её тип в Types, а "права" - в RightsTypes. А таблица Rights - это внутренняя таблица самой базы, она создается и модифицируется разработчиком (который и продумывает межанизм реализации прав доступа). А слова "Администратор", "Методист" и т.д. - это просто текстовые строки в поле UserTypes.Name...

Где-то так, для начала...

White OwlЕсли тебя не смущает что в будущем для ролей "директор" или "завуч" придется создавать новые таблицы, а для удаления ненужных ролей удалять таблицы.... то вперед.

Ни у традиционалисты будут тебя материть за изобретение велосипеда.Пока набирал - пропустил пост
И да будем материть - ибо в этом случае Оккам своим серпом по одному месту... ну вы поняли...