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

примерно описал структуру...

как нужно разделять роли привилегии права доступа на данные подскажите принцепы, ато у меня так всё размыто ничего конкретного не вижу.

спасибо!!!

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

Настраивать от имени отдела кадров - это интересно...

То что менеджеры работают со своими регионами и со своими поинт менеджерами, поинт менеджеры со своими городами, клиенты имеют доступ только для чтения(например)... - эт. понятно

Мне непонятен сам принцип разбиения на роли:
1. вопервых роли - это независимые множества прав или это жосткие рамки,
т.е. мне несовсем понятно если это независимые множества прав, тогда как например можно совместить роль поинт менеджер с ролью директор, или менеджер с ролью поинт менеджер ?
2. как нужно создавать роли:
можно ли сказать например, что роли - это:
- роль директор
- роль поинт менеджер
- роль менеджер
- роль главный менеджер
.....
или роли это что то другое ...?
3. как вообще нужно определять множество ролей ?
4. Нужно ли делать иерархическое выделение ролей, точнее как его нужно делать:
например начальник отдела должен иметь доступ к данным своих подчинённых, но он может например иметь доступ только по чтению, или частичный доступ, а может и всё... какк в этом случаи выдавать ему права ?
5. например если есть роль Менеджер да....
а есть такая роль типа чел который создаёт отчёты по информации менеджера... но у неё есть доступ к договорам например... как к немк добавить роль менеджера, но чтобы она была только для чтения ?
т.е. роль менеджера это обязательно будет RW, или для роли нужны какието параметры для её уточнения... ?

кажись разобрался...
- Во первых: нужно определится на какие обьекты нужно будет выдавать привилегии: это будут таблицы, представления, ХП, Package...
- Во вторых: Например для одних юзеров нужно использовать доступ к отдельным строкам, а для других - к отдельным городам(т.е. множествам строк...) т.е. кроме обьектав есть также способы выделения прав на обьект.
Эти способы можно комбинировать напримнр для юзера user123 разрешить полный доступ к МП Киева + 10 МП из Донецка...
- Таким образом у меня есть множество обьектов, и для каждого обьекта множество способов выделения прав на этот обьект. (т.е. составляю where с разными аддитивными условиями.)
- После этого я создаю роль, для которой определяю множество привилегий.
- далее создаю роли - группы, которым присваиваю наборы ролей.
- далее создаю юзера, и назначаю для него группу.

Разве что проблематично организовывать иерархическую структуру доступа к ролям...
Блин с этим проектированием можно з...тся...

А ещё нужно придумать административный модуль(или забить...)

А ещё потом нужно будет придумать как делать хранилища данных OLAP Версионность...
и ещё там чтото появится обязательно что я не предусмотрел

вобщем весёлая жизнь до лета обеспечена....

И ещё:

как лучше: чтобы роли статически назначались юзерам, или чтобы они както хранились гдето отдельно, и назнакчались во время коннекта... реально ли так сделать и нужно ли это вообще ??

возможно ли вообще не хранить постоянно уч записи юзеров, а создавать их во время коннекта и удалять после коннекта както... ???

А как вообще нужно совмещать выдачу привилегий на Обьекты БД, с привилегиями на доступ к частям приложения ?
Как это можно совместить ???

И нужно ли вообще в бд хранить инфу о виде приложения для юзера ?

ShtockА разве доступ к части приложения не есть доступ к части БД (а роли именно для этого нужны)?

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

Мне это и непонятно как совмещать права к данным и права к частям интерфейса, чтобы они както синхронно выдавались чтоли...?

Shtock
Я, например, предпочитаю, что если что-либо нельзя делать в приложении, то пусть БД ругнется об ошибке контроля доступа, а не прятать интерфейс. Тем самым Вы еще и убиваете 2-го зайца: можно настучать по голове любопытным, а только так их можно выловить -;)

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

Shtock
P.S. ПОделитесь секретом, а почему Вы вечером активируетесь?
[/quot]
почемуже невсегда...
просто в последнее время типа разбираюсь в чёмто сутра, а под вечер задаю вопросы в форуме чтобы завтра с утра поразбираться...
хотя... это не специальный режим, когда на чёмто зацикливаюсь тогда и лезу в форум...