Всем привет!
Я тут мучаюсь одним вопросом, каким образом мне хранить права для сотрудника.
Вродебы всё просто, даёшь права пользователю на таблицу, в зависимости от того что ему надо, ну например добавление, редактирование.
Но возникает тогда проблемма, а если например таблица хранит данные разных складов например. И допустим редактировать количество на складе А пользователю можно, а редактировать количество на складе Б нельзя.
Дак пользователю выдаются права на всю таблицу, и не важно какой признак склада у позиции.
Другой вариант, это когда например редактирование заказ-наряда. В статусе "В работе" заказ-наряд можно редактировать, а в статусе "закрыт" редактировать нельзя.
Как в такой ситуации поступить?
В принцепе конечно можно как и в первой ситуации, так и во второй сделать просто программным путём. Ну например сам клиент(приложение) не даст редактировать заказ-наряд если статус "закрыт".
Но в такой ситуации, пользователь просто подключится к БД через другой клиент, в котором он может просто командами управлять и изменит количество товара на чужом складе или отредактирует заказ-наряд со статусом "закрыт".
Можно конечно один склад хранить в одной таблице, а другой склад в другой таблице, но это может привести к куче таблиц, будет противоречить золотым правилам создания БД, и не решит проблемму второго примера.
Есть ещё и третий вариант, гораздо более подходящий, но как это будет влиять на скорость я даже не представляю.
Смысл его заключается в следующем: Все права пользователей на определённые операции(добавление, редактирование и т.д.) хранятся в таблице например Right. Операции с данными производятся исключительно через хранимые процедуры.
Сама хранимаю процедура принимает такие данные как Пользователь, пароль, Код операции, и необходимые данные для проведения операции. Затем процедура проверяет действительно ли есть такой пользователь и если есть то проверяет его права, и если всё нормально то выполняет операцию.
Тоесть в первом примере если у пользователь существует и у него есть права, и он работает с тем складом с которым ему можно работать то выполнить операцию, а если нет прав или склад не тот то просто не выполнять.
То же самое в принцепе и с заказ-нарядом. Если у пользователь существует,у него есть права и заказ наряд не в статусе "закрыт" то можно редактировать, иначе нельзя.
При этом давать права только на выполнения хранимых процедур.
В итоге пользователь уже ни из какого приложения не сможет сделать то чего ему нельзя, как бы ему этого не хотелось, но с другой стороны скорость на этом теряется, ведь каждый раз необходимо проверить на существование пользователя или не отключен ли он, потом проверить права на операцию и т.д.
А если происходит большое добавление данных, например в накладную добавляется прайс лист... Через INSRT INTO уже не добавишь, а через процедуру будет каждую строку на права проверять.
Вообщем вот такая ситуация! Хотя конечно наверное можно проверять пользователя как то по другому или даже просто есть в БД функция которая выдась пользователя из под которого идёт выполнение процедуры, но всёравно проблеммы скорости это не решит на много.

Если у кого есть какието размышления на эту тему, то жду ваших сообщения 24 часа в сутки! :-)

BelyКакая у вас БД ?

В оракле, например, есть свои подходы как с такими вещами разбираться, у MS - свои.

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

Платформа пока не выбрана, но вот я и выбираю!
Как вариант это либо MS SQL либо PostgreSQL !

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


Насчёт RLS не знал, но сейчас посмотрю что это такое, может он меня полностью и удовлетворит.

Насчёт того что ХП нарашает безопастность - с этим я полностью не согласен. И в отличии от тригоров проверку через ХП гораздо легче организовать и можно сделать гораздо более гибкую! Просто в таблице иметь данные: Id пользователя, Id операции, Enabled ! И всё! Если у него есть права, то Enabled=true ! Нет то False или вообще строки в правах не будет.
А ХП обойти не удастся, так как кроме ХП давать права больше ниначто не буду. Вот и всё!
И никак они это обойти не смогут! И использование тригеров факически будет использовать теже принципы что и ХП !

Кот МатроскинПростые случаи покрываются вьюшками (скажем, описанные Вами разные склады и разные статусы документа), сложные - да, своей системой безопасности и процедурами. Опасения на тему производительности процедур имхо неоправданы - можно сделать процедуру добавления прайса и проверять права один раз. Другой вопрос, что решение через процедуры - трудоемкое.

Решение через процедуры - для меня совершенно не трудоёмкое. Я уже такой принцеп использовал в одном из своих приложений. Но с той БД работает мало народу, поэтому на скорости это не особо отражается! А я планирую сейчас написать приложение на 100 пользователей, а может и больше, вполне вероятно и 500 пользователей! Ну дак вот и боюсь я при такой ситуации дополнительная проверка прав усугубит дело!