>> Хотелось бы организовать доступ к базе с разделением полномочий.

Работал на Oracle счас много делаю на Postgres. Механизм работы описанный ниже - не только мой стить - стиль многих коллективов разработчиков в финансовой сфере...

Общая безопасность и доступ к обьектам :
1. На все таблици существуют вьюхи и клиент читает только их, тем более
часто в разработках плоские таблици используются редко (только справочники некоторые - все равно есть вьюхи), организация связи таблиц тож во вьюхах.
Прав на таблици у клиентов вообще никаких нет. В итоге имеем для чтения
данных только вьюхи.
2. Модификация данных только через функции. Во первых всю бизнес логику
я размещаю только на серваке, во вторых всяческие проверки/валидности тож на серваке. Функцию создаем с опцией - например SECURITY DEFINER - она будет работать с правами создателя, юзеру дадим права только на выполнение функции. В итоге модификация данных происходит по строгим правилам описанным в функции.

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

Теперь про разделение полномочий юзверей:

1. Можно сделать свою табличку юзверей и много колонок с различными признаками (о синхронизации создания юзверя в табличке и на сервере я рассказывать не буду). Создаеш функции проверки всяки какие угодно и ...
2. Для чтения нужных строк во вьюхе(она уже готова) вставляеш например

"where check_read_record(user) = 1" - "check_read_record" - это название функции которую сделаеш.

3. Для модификации данных в процедуре вставляеш например

" if (check_add_record(user) = 0) then
RAISE EXCEPTION \'У вас нет прав на добавление записи !\';
end if;
"

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

Николай.

2 guest_20040621

> То, что описал Николай постом выше - хорошее решение, но несколько
> однобокое. ;) Попробуй его реализовать - поймешь, почему.

Я думаю не только мне хотелось бы услышать мнение об однобоком решении
публично. Зачем изобретать велосипед дважды - может ваше обьяснение
поможет кому-то (не только мне), а может не только поможет но и направит
на свежую струю - на то он и форум.

Без сарказма - хотелось бы услышать ваше мнение.

Николай.

2 guest_20040621

И все же не совсем понял - каковы ограничения ?

>> На все таблици существуют вьюхи и клиент читает только их
> Это хорошо, но иногда требуется писать. ;)

У меня не требуется - не даю в силу того что шаловливые ручки зная свой пароль могут например через драйвер ODBC и Excel или Acces получить доступ к разрешенному обьекту. Ето если делать нормально, можно конечно сделать изначальный вшитый вход с универсальным паролем в морде - строил и так - но не считаю что это хорошо. Ну это утрировано ...
Нет у меня запросов со словами insert, update, delete.

>> Модификация данных только через функции.
> Это тоже хорошо. Только накладывает ограничения на dbms.

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

>> where check_read_record ...
>Хм... оно конечно тоже правильно. А если потребуется не rwe, а более >сложная модель? Все переписывать? ;)

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

>Почему, собственно, и было сказано: хорошо, но для конкретной реализации, >а не для общего решения.

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

Может я чего не понял в однобокости такого решения и вашего понимания DBMS?

Николай.

2 guest_20040621

>> У меня не требуется
> Вот и я о _Вашем частном случае_. В _Вашем частном случае_ писать в базу > не требуется. Согласитесь, для большинства баз данных это не есть
> характерное требование.

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

>> Для реализации своей системы на предприятии - хорошо, быстро, удобно,
>> сопровождаемо.
>В сравнении с чем?
>Представьте себе количество геморроя при переходе с PostgreSQL на, >скажем, db2. Не думаю, что Вы вспомните о том, что это >было "хорошо", "быстро", "удобно" и "сопровождаемо". ;))

На предприятиях со своим софтом - переход с базы на базу редкость и это серьезное решение.
У меня был переход с InterBase на MSSQL2000 в крупном учебном центре.
Занял переход 3 дня. Клиенты практически не менялись - только один обьект - соединение к другой базе. Ибо все остальное например
"select ..." или "exec ..." без изменений. А переписать синтаксис процедур
даже просто и приятно - лишни раз синтаксис повториш.

В сравнении - например нам принесли демку системы клиент-банк.
Крутая типа куча баз MySQL, Oracle, MSSQL. Ну поставил я на Oracle - ни одного пакета, ни одной функции или триггера. Использовать такой сервер
как хранилище табличек - извращение. А требования для клиента немеренные и сетку трафиком забивает - врагу не пожелаеш. Примочка - DBMS. А кому это надо. Да для продажи круто - бедные узвери.


Ну думаю все это субьективные мнения и все остальное превращается во флейм. По крайней мере у задавшего вопрос есть пару вариантов пусть пробует. Удачи.