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


Обычно хватает трех таблиц:
- список пользователей
- список возможных ролей
- список соответствий пользователь-роль
Плюс этой схемы по сравнению с много-табличной - можно легко создавать новые роли (просто добавить строку в список ролей и все). А в случае роль-таблица - надо будет создавать новую таблицу.
Но собственно функциональных отличий между традиционной схемой и твоей нет. Если тебя не смущает что в будущем для ролей "директор" или "завуч" придется создавать новые таблицы, а для удаления ненужных ролей удалять таблицы.... то вперед.

Ни у традиционалисты будут тебя материть за изобретение велосипеда.


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

rockclimberscymaksrockclimber,

как быть с тем, что скажем у пользователя студента нет логина, а у администртора на есть?А в чем проблема? Проблема будет, когда заказчик полгода спустя скажет - а давайте сделаем логины студентам, пусть расписание сами узнают! И вы еще раз сделаете то, что уже делали по отдельности для администраторов, методистов и учителей.
Вместо того, чтобы сделать один раз для всех и забыть.Вы оба путаете наличие логинов с обязательностью паролей.

skoleAndreTM, ++
Только правила доступа здесь не нужны, это делается на уровне приложения, то есть по умолчанию доступа нет ни у кого, но на уровне приложения открываешь доступ для админа - удалять, для методиста редактировать.Вот за это "на уровне приложения" - убивать на месте.
У Васи версия клиента номер 1, он может будучи учеником может править урок. Ну баг там был в приложении. Ты обнаружил баг, исправил его и выпустил версию приложения номер 2. Счастье? А фиг! Вася зная о баге не стал обновлять свое приложение и спокойно правит уроки.
А директор школы сказал: "а почему это методист не может создавать уроки? Дайте ему доступ" и начнешь ты опять править приложение а потом распространять его...

UsmanОбновилВроде-бы, кто-то, не так давно, намекал что TC нарушает принципы нормализации.
Не помнишь кто это был?

scymaksЯ создаю небольшую программку, которая будет использоваться в частных школах.Кстати, уточни пожалуйста, какой СУБД ты пользуешься и пользуешься ли вообще какой-нибудь?
Просто у большинства много-пользовательских СУБД уже есть готовые (системные) таблицы пользователей и системы ролей и/или групп. И твоя начальная задача решается не создаваемым таблицами а простым использованием имеющихся средств.

AndreTMWhite OwlВот за это "на уровне приложения" - убивать на месте.Я, наверное, выразился как видел. Skole - как видел он. А говорим мы о разном.О разном?
Ну вот я говорю о том что:
Вариант 1) Права пользователя жестко завязаны на его роль. Тогда таблица Rights не нужна вообще и приложение узнав к какой роли пользователь принадлежит включает/выключает доступ до определенного модуля.
Вариант 2) Роль это глобальное понятие, например Учитель. Но учитель биологии не может править уроки по физике и наоборот, тогда нужно вводить "вторичная роль" и доступ до модуля "учитель" для МарьВанны выдается по ее роли, а потом гранулируется второй раз при помощи таблицы rights и выдается доступ до классов соответствующего типа.
В обоих вариантах доступ разграничивается на сервере.

А skole предлагает:
skoleТолько правила доступа здесь не нужны, это делается на уровне приложения, то есть по умолчанию доступа нет ни у кого, но на уровне приложения открываешь доступ для админа - удалять, для методиста редактировать.
То есть по его мнению, если читать дословно, то получается что пользователь приходит в базу данных и не может ничего сделать на уровне СУБД. Потом в приложении отрабатывает некая волшебная функция которая разрешает этому конкретному пользователю что-то делать. В итоге получаем нечто теоретически невозможное.

Предположим что skole описался и он имел в виду что пользователь может делать все что угодно на уровне СУБД, но приложение прочитав роль пользователя и узнав что это роль с ограниченными правами выключает доступ до определенных модулей. (Это уже вполне реальная ситуация и я ее видел в живую неоднократно.) Но тогда, смотри мой предыдущий ответ для skola. Это абсолютно незащищенное от злоумышленников решение, и оно чрезвычайно шатко когда дело касается целостности данных.
В случае если СУБД без-юзерного типа (FoxPro, SQLite, etc), то это единственно возможное решение и тогда действительно будет нужна таблица users и ручное придумывание системы разграничения прав доступа. Опасно и ненадежно, но увы без вариантов.
Но если СУБД имеет встроенную систему распознавания пользователя (MS SQL, Oracle, MySQL, etc) то надо ею воспользоваться и пользователь пришедший в СУБД будет иметь частичные права (по его роли) не смотря на клиента. В этом случае делать права доступа на уровне приложения - лишняя работа. А если на такой СУБД давать права изначально на все, а потом делать правила доступа на уровне клиента, то это повод оторвать разработчику руки по самые гланды.

AndreTMЯ хотел сказать, что привязки "роль-права" доступны в приложении. И "ученик<+/->модификация урока" - это связка в RightsTypes . На уровне приложения. А вот запись в Rights "модификация урока" <=> "GRANT/REVOKE INSERT,UPDATE,DELETE ON TABLE lessons TO ..." и будет на совести разработчика...А при чем здесь разработчик? Это работа для Администратора а не разработчика. В модуле Администратора будет кнопка "дать/отнять роль учителя" и по ее нажатии будет запускаться эта команда. И все собственно. Вот если TC будет делать разграничение по типу уроков (биология-физика-рисование), то тогда надо будет делать еще и запись в Rights с указанием какие именно строки из lessons можно править этому пользователю.

skoleВнесем ясность, пользователь приложения не есть пользователь БД.Все, дальше можно не читать.
Пользователь приложения не будет пользователем БД только в одном единственном случае - абсолютном отсутствии БД.
В общем: "В школу!"

rockclimberя уже сказал и повторюсь еще раз: это просто холивар, бессмысленный и беспощадный.Неправда. Это не холивор, а нашествие молодежи работавшей на одном-двух микро-проектах и не имеющих реального опыта.
Не сталкивались они с кретинами юзерами узнавшими логин-пароль под которым ходит в базу приложение и попытавшимися "подправить" базу напрямую. Не видели как стажер делает дамп базы и продает ее конкурентам, а большие боссы почему-то очень сердятся.
Не встречались наши носители розовых очков с нуждой иметь два-три разных клиента к базе данных... Вынос бизнес-логики на приложение в этом случае превращается в настоящий рай для энтомологов и психиатров.
Не было у них в жизни розысков "какая сволочь платежку исправила?!"...
Юность это счастье.

scymaksЯ использую PostgreSQL, но не хотелось бы использовать каких-то слишком уж нативных средств. Потому как в будущем возможна миграция на Oracle или что-то еще (не по моей воле).Не обязательно использовать нативные средства через нативный синтаксис. Вполне можно ходить к базе через ODBC/ADO и делать всю работу через универсальные интерфейсы. Они спрячут почти все нативность внутрь драйверов и потом можно будет просто перенаправить DNS на другую базу и все. Переделки в этом случае все равно будут, но минимальные.

Ну и в конце-концов, если заказчик хочет Оракл (и готов его купить) - можно взять бесплатную GA редакцию и разрабатывать свой проект на ней. Практически все современные СУБД имеют сейчас бесплатные редакции предназначенные для разработки пилотных версий и/или студенческих игрищь.
Но я очень советую заранее определиться с СУБД и писать сразу на ней. Даже если ты специально будешь ограничивать себя диалектом SQL-92 - все равно рано или поздно столкнешься с необходимостью сделать кое-что нативно.

Dima TВсе должно развиваться эвалюционно. Образный пример: если на запорожец приладить колеса от вездехода, то вездеходом он не станет. Станет чуть-чуть проходимее, но не вездеходом.
Это я к тому что один правильный кусок программы не спасет ее от взлома, просто чуть-чуть его усложнит.Видишь ли, дизайн систем это не запорожец. Дизайн систем это ответ на вопрос "есть у запорожца мотор и колеса или нету". Сейчас на запорожец можно в принципе поставить колеса от вездехода, но гусеницы или пропеллер к нему не приладить никак. Для таких переделок эволюции мало, для них полный ре-дизайн нужен. А если ты изначально хотел получить вертолет, но сделал запорожец тебе никакая эволюция уже не поможет.
Так и здесь. Если изначально пойти по пути наименьшего сопротивления и сделать секьюрити и бизнес-логику на уровне приложения, то потом тебе придется делать полный рефакторинг и клиента и сервера чтобы перенести их на сервер.

Dmitry EliseevМне вот интересно, а как быть (в случае когда доступом рулит БД), если требуется доступ только к определённым записям в таблице, а не ко всей таблице ? Например, чтобы пользователь 1 мог удалять только свои записи, просматривать записи пользователя 2, но не видел записей пользователя 3 и 4 ?А это зависит от СУБД.
У большинства для этого есть специальные модули, которые стоят специальные деньги.

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

Другой вариант: делаешь view (обновляемый если нужно) и в нем уже даешь доступ к определенной записи для юзера по нужным правилам и заставляешь всех юзеров работать с этими представлениями (просто отбираешь доступ к таблице, разрешаешь к представлению).
Собственно говоря, "решения из коробки", те самые дополнительные модули для СУБД, именно так и делают. Но они не создают отдельное представление, а подменяют обращение к реальной таблице на обращение к виртуальному представлению. Ты определяешь правила доступа к записи, а сервер уже будет на каждое обращение к записи проверять этот набор правил.

Dmitry EliseevИнтересный вариант :). Особенно если пользователей не один десяток. Представляю себе размер хранимых процедур. А как наверное весело реализовывать динамическую раздачу прав. Чтобы админ (роль приложения, а не СУБД) мог самостоятельно разруливать какие действия и с какими записями какой пользователь мог осуществлять.Не вижу проблем.
Каждая запись имеет "признак принадлежности". Это может быть и имя юзера (если доступ надо делать персонализированным) или код отдела/филиала/группы/итп.
А потом просто


или

И все.

Dmitry EliseevА уж вести логирование бизнес дейстивий... видимо тоже с помощью хранимых процедур ?Ну а это то какие сложности у тебя вызывает? Триггера в школе не проходили?