FreemanZAVДа, в такую погоду лучше пивка

А под пивко можно обсудить следующий вопрос. По какому принципу в Oracle "принято" заворачивать функционал в один пакет, при условии невозможности разграничения прав доступа на функционал внутри пакета?

softwarer,

авторЭто довольно бессмысленный вопрос, примерно аналогичный "а по какой схеме в Аргентине принято играть в футбол?"

Вопрос, всё-таки носил практический смысл. Сожалею, что дополнительно этого не указал и допустил возможность различных толкований.

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

Начну с того, что считаю в принципе недопустимым раздачу прямых грантов пользователям на таблицы. И позволю себе привести другой пример. Маркетинговая акция - т.е. некая активность, при выполнении условий которой клиент получает определенные бенефиты. Как легко себе представить маркетинговая акция - это не одна таблица. И нужно решить простую задачу. Разрешить заводить маркетинговые акции рядовым менеджерам дирекции по маркетингу, но включать\выключать акцию дать возможность только определенному кругу лиц. Я правильно понимаю, что я должен иметь как минимум два пакета? Первый - отвечающий за создание и модификацию акций, второй - за включение\выключение их? Рядовым менеджерам грантовать только первый, "определенному кругу лиц" - оба?

Теперь, если я захочу разделить права на просмотр\модификацию акций межу разными группами рядовых менеджеров, что я должен сделать? Создать отдельно пакеты, в которых будет код только на модификацию\только на просмотр? Опять грантовать кому один, а кому два, а "определенному кругу лиц" все три?

авторАльтернативно, никто не мешает воспользоваться row-level security, опять же зарезать пользователю возможность работать с недоступными ему данными.

Нет, нет. Мой вопрос не касался row-level security, которая "встроена в Oracle" и которая реализуется с помощью дополнительных телодвижений в MS SQL. Вопрос касался именно прав на выполнение того или иного функционала в виде хранимого серверного кода.

FreemanZAVМожно много говорить, что пакеты не нужны

Я этого не говорил.

FreemanZAVпонимаешь все преимущества

Вот я и пытаюсь их понять. При этом не забыв про недостатки.

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

По-моему это уже мы как-то обсуждали? О хранении "всякой фигни". Если я не прав, то можно Вас попросить какой-нибудь пример?

FreemanZAVНу и ещё, как вариант, можно свою ACL систему организовать.

Ни есть ли Oracle Database Vault "своя система ACL"? Если в другой СУБД для реализации каждый раз нужен строго определенный и ограниченный набор объектов, будет ли эта реализация чем-то отличаться от "своей системы ACL" в Oracle?

softwarer,

авторПожму плечами. В некоторых древних системах и использование SQL считалось недопустимым.

Не совсем понял суть высказывания. Т.е. Вы считаете "это" допустимым? Под "это" я понимаю возможность обхода конечным пользователем заложенной в серверный код бизнес-логики в случае наличии прямого доступа к таблицам.

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

Вопрос носил характер вполне обычного ролевого разграничения прав доступа. Мы же о бизнес-логике говорим? Т.е. о бизнес-процессах, а там действия выполняют роли, а не пользователи, таблицы, или пакеты.
авторЧто я хотел бы донести, так это то, что вопрос перпендикулярен понятию пакетов.

Мне казалось, я задал вполне конкретный вопрос о прикладном функционале пакетов.

авторТа проблема, в которую Вы пытаетесь их загнать


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

авторкак только я спрошу "как мне програнтовать Васе возможность выполнить ХП с параметром А и при этом не давать выполнить ту же ХП с параметром Б". Разница в том, что в Oracle её можно решить, не теряя преимуществ пакетов. Например, если Вы хотите грантовать одиночные процедуры - я за пару минут напишу код, который будет пробегать по установленным пакетам и для каждой процедуры A из пакета Б создавать хранимку Б_А, её вызывающую. Как раздать гранты, надеюсь, пояснять не надо. То, что удобство программирования при этом не теряется - надеюсь, тоже.

Не совсем понял, причем тут "за пару минут напишу код"?! Я сейчас не веду речь о каких-то workaroundах. Я о стандартном функционале веду речь.

FreemanZAV,

авторЧестно - нет никакого желания ничего объяснять.

авторНичего не могу сказать, почитайте документацию

Спасибо! Ваша позиция понятна.

Yo.!,

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

Я правильно понимаю, что это построение "своего" ACL над имеющейся системой разграничения прав доступа сервера?

FreemanZAVНу я никак не могу, при всём желании, объяснить лучше, чем документация.

Если бы всё можно было бы черпать из учебников, то зачем нужны учителя?!