>Повторюсь: Вы разработали определённую схему работы с данными,
>которая хорошо ложится на модель безопасности "по умолчанию", Если бы я это разрабатывал. Сделано людьми, для которых "безопасность" - слово из газет. У них проблема решена очень просто - всем пользователям даются все права на уровне сервера. Попытки навести порядок до сих пор безуспешны.
>принятую в MySQL, и плохо - на аналогичную модель, принятую в
>ORACLE. Если бы Ваше приложение разрабатывалось изначально под
Иерархическая модель раздачи прав доступа не специфична для MySQL. Эта идеология используется в файловых системах, например NetWare.
Что любопытно, в Unix используется иной подход и получить наследование прав по дереву совсем непросто.
>Есть такое понятие как 'shared schema'. AFAIK пользователям на неё
>можно назначить комплект прав "по умолчанию".
Спасибо за наводку!
То есть вопрос теперь формулируется так - стоят ли удобства Enterprise Server геморроя с его установкой для трёх пользователей?
>Описанная далее конфигурация - другого рода. В Вашем примере приложения
>связаны по общим данным. Особый случай, однако.
Почему-то этот "особый случай" постоянно встречается в системах с распределённой обработкой. Хоть банки, хоть лаборатории. Заказчик всё время требует одно и тоже - есть "мои данные", есть данные "моей группы", есть "общие данные".
Я ввожу "свои", могу править "групповые" и читать "общие".
>объектов схемы пользователем A. См. "Oracle® Database Security Guide",
>раздел "5 Authorization: Privileges, Roles, Profiles, and Resource
THNX, я пока пошёл курить Managing Enterprise User Security.
Мне сильно не нравится идея обвешивать таблицы служебным кодом, который не сможет понять обезьяна-администратор.