offsites Разбить их на группы-роли и потом только добавлять юзверя в группу.
роли - это НЕ группы, а строго ПРОТИВОПОЛОЖНАЯ группам вещь

группы нужны чтобы складывать права.

а роли - чтобы вычитать права.

повторяю:

Ariochесли тебе не нужны роли, то тебе не нужны роли

роли были придуманны именно затем, чтобы у одного пользователя были разные профили безопасности

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

Если тебе нужны роли как просто шаблоны прав, именованные контейнеры готовых полномочий - не вопрос, пользуйся ими так.

И сделай три stored procedure

1. получив имя пользователя и имя группыроли процедура, проверив права на группу у пользователя, перебирает все права группы и добавляет такие же права пользователю. Это чисто служебная функция.
2. получив имя пользователя удаляет у него все права, потом перебирает все назначенные ему группыроли и для каждой вызывает процедуру 1. Это будет функция "назначить права пользователю Вася Пупкин"
3. получив имя группыроли перебирает всех ей назначенный пользователей и вызывает функцию 2. Это будет "триггер", который ты будешь вызывать после каждого изменения прав у какоу-нибудь группыроли.

Впрочем, устраивать такой abuse ролям имеет смысл только если ты им права назначаешь "врукопашную" через что-то типа IBExpert.
Если же ты это делаешь из своей самописной админки сделаннйо для твоей программы - то роли тут вообще не нужны, а в качестве замены групп - именованных контейнеров для готовых наборов прав - вполне сгодятсья специальные пользователи тиа template$user1, template$user2, template$user3 и т.д.

offsitesКто такие эти специальные пользователи?

это пользователи в терминах сервера БД, которые не соответствуют ни одному реальному человеку. Они просто именованные контейнеры прав.

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

fdbm,

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

придётся делать общедоступный список-меню последних пользователей, как в домашней winxp, причём каждый сможет посмотреть под какой ролью последний раз входил какой человек.

кроме того "operator_adm" с точки зрения пользователя-домохозяйки - абракадабра бессмысленная. Роль должна быть понятно описана в несколько слов на русском языке.

Ну и наконец - зачем они вообще нужны эти роли? и уж тем более зачем они нужна пользователям?

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

---

Есть две модели, "аддитивная и субтрактивная" :-)

Либо "принцип одного окна", когда пользователь запускает One True Program в которую собрана вся функциональность комплекса. И там в этом окне он может открывать только части, ему доступные. Но разные "свои" функциональные части он может открывать одновременно. Тогда нет смысла делать из одной программы несколько соединений к БД одного и того же пользователя с разными ролями. Тогда пользователю БД нужно дать объединение всех "малых комплектов" прав, чтобы он в одном соединении работал со всеми функциями.

Либо "разделяй и властвуй", когда комплекс разделён на несколько узко-специализированных программ, и пользователь запускает ту программу из комплекса, функции которой ему будут в этот момент нужны. Тогда ему "лишние" права не нужны и опасны, факт. Но тогда роли отражают те же прикладные задачи, что и разные программы комплекса и в каждой программе будет одна жестко заданная роль, необходимая именно этой программе для обработки её конкретного функционала. Как вариант, внутри этих программ можно дополнительно ограничивать пользователей (типа старший бухгалтер / помощник ст.б. / младший бухгалтер / кассир со всё сужающимися правами и обязанностями), тогда программе может соответствовать несколько ролей-матрёшек, из которых программа выберет сама, когда посмотрит что это за пользователь в неё входит и как конкретно нужно подрезать ему крылья.

В обоих случаях путать пользователя непонятными и ненужными ему ролями нужно ровно настолько же, насколько ему нужно объяснять разницу между CHAR, VARCHAR и TEXT BLOB .