Добрый день!

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

PS INGRES/Enhanced Sequrity не предлагать:-)

2 YellowMan

конечно рассказать!

нашел немного про права здесь http://www.ibase.ru/devinfo/oop_rdbms.htm , но хотелось бы конкретный пример и с использованием ролей и юзеров сервера

на мой взгляд юзера сохранять, как носителя прав нельзя

т.к. его могут уволить, не разумнее ли взять все его роли первого уровня?

2 Jimmy

>>Конечно, можно исходить из того, что админ забыл удалить его из списка, но такого админа нужно в шею гнать.

Ну и (в моей схеме, во всяком случае) проще использовать ниладическую функцию SYSTEM_USER, чем париться и добывать список ролей, к оторым пользователь относится.

далее только ИМХО и более абстрактно:-)
права на объекты -это вещь, которую нужно стараться максимально сделать независимой от быстроменяющихся сущностей, уж если нужно дать права отдельному пользователю на запись, то это должно быть скорее исключением, чем правилом

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

хотя полностью уйти от указания чего либо для юзеров не получится. как ,например, указать права юзера в его роли(по отношению к другим членам)

в НТ есть всякие админы, аккаунт админы, принт операторы и т.д., а в MSSQL встроенные роли для прав на отдельные строки не подходят


или я в чем-то не прав?

PS просто хочу слишком сладкого: сделать такие права, чтобы они позволяли много, но не отходя от ролей:-)))

PS если юзера перевели из отдела в отдел, следовательно, вынули и переложили из ролей в роли, снапшот ролей юзера на момент записи строки остался неизменным, а вот юзер уже записи не видит

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

как я понимаю из обсуждения, возможность доступа через view отсекается, как малозначительная? процедура-это конечно хорошо, но лишаться из-за прав доступа view не хочется

права доступа на столбцы- для моего случая это слишком круто, тут, видимо, только процедуры помогут

а как вы рассмотривате такой вариант:

таблица Orders(ордера, клиенты или что угодно)

Id, primary key
<other>

таблица Rights

OrderId, foreign key
Group, MSSQL role
Access битовая маска Select/update/delete

view
...
from
Orders
left outer join Rights on OrderId=Id
group by
...
having
sum(is_member(Group))<>0

вот еще где-то нужно приткнуть Access:-) и будет порядок. Если учитывать Access, то придется к каждой связке Role,User приписать его права в этой группе. Это не очень хорошо, т.к. при удалении юзера такая связка останется, но за все надо платить