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