Необходимо обеспечить наличие в БД некоторого набора свойств для пользователя MS SQL, вполне устроит таблица с определенным набором полей. Допустим, это будет таблица



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




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

в Оракле это называется Row Level Security и встроено в сам движок
есть ли подобное у мелкомягких, не знаю
тем более версия не указана

Версия MS SQL 2000

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

В оракле я как раз и подсмотрел конструкцию




Только там вместо PIdUser было что-то типа GetUserId() и работало при использовании любого клиента, хоть SQL Plus

> В оракле я как раз и подсмотрел конструкцию

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

Хорошо, что так хорошо все в оракле, но мне нужно в MS SQL.

APP_NAME(), приложение
HOST_NAME(),  хост
SUSER_SNAME() юзер

Только я не понял, откуда MSSQL должен знать кто в каком подразделении работает.

Посмотрите как предлагает это делать микрософт, для сайтов и т.п. приложений
http://msdn.microsoft.com/en-us/library/aa478948.aspx

>Правильный$Вася   (25.08.10 23:26) [3]
думается, что Oracle как раз и дополняет пользовательский запрос чем-то типа:


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

>zubr   (26.08.10 13:30) [6]
Эта схема данных имеет прямое отношение к RLS?
Вопрос автора читали?

в Oracle это называется Virtual Private Database

> Игорь Шевченко ©   (26.08.10 15:44) [9]

по-моему, всю дорогу как-то label security называлось (уже с магией уровня ядра, не dbms_rls)

> по-моему, всю дорогу как-то label security называлось


Это trusted oracle

> Игорь Шевченко ©   (26.08.10 16:46) [11]

ну да, она же Элла Кальценбобер, она же Манька-Облигация

> Кщд   (26.08.10 13:57) [7]

правильно, но это делается так, что ни пользователь, ни программист об этом не знает, а долько БД-админ

> Petr V. Abramov ©   (26.08.10 16:14) [10]

label security - это так сказать "проба пера", замененная позже на RLS и не рекомендуемая для новых разработок

> APP_NAME(), приложение
HOST_NAME(),  хост
SUSER_SNAME() юзерТолько
> я не понял, откуда MSSQL должен знать кто в каком подразделении
> работает.


спасибо попробую, но уже через неделю - отпуск однако :-)

MSSQL узнает из таблицы которую я сделаю, и установлю связь пользователь = подразделение

> Правильный$Вася   (26.08.10 18:29) [13]


> label security - это так сказать "проба пера", замененная
> позже на RLS и не рекомендуемая для новых разработок

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