>Для Oracle - в своей. Для MySQL - в той, где у
>него достаточно прав. Фокус в том, что этим View должны пользоваться
>остальные.Вполне пристойным вариантом может быть изготовление PL/SQL процедуры,
обеспечивающей создание и/или модификацию объектов в нужной схеме,
включая автоматическую простановку нужных прав.
Повторюсь: Вы разработали определённую схему работы с данными,
которая хорошо ложится на модель безопасности "по умолчанию",
принятую в MySQL, и плохо - на аналогичную модель, принятую в
ORACLE. Если бы Ваше приложение разрабатывалось изначально под
ORACLE, портация на MySQL вызвала бы никак не меньше боли в одном
месте (tm).
>Увеличивается не только объём писанины, но и риск ошибки, когда
>права будут отданы "не тем парням".
Там, где велик объём писанины, необходима автоматизация.
И в случае с ORACLE она вполне возможна.
>>В ORACLE дерево другое: база -> схема -> таблица -> строка.
>
>В Oracle дерево такое - tablespace->table->row. Я никак не могу дать
>права на чужую схему, мне приходится делать GRANT на каждый объект .
Есть такое понятие как 'shared schema'. AFAIK пользователям на неё
можно назначить комплект прав "по умолчанию".
>>несвязанных друг с другом приложений. А если хоть одно из приложений
>>требует "отдай мне всю базу целиком", то такая конфигурация становится
>>небезопасной.
>
>Пример конфигурации такого рода:
Описанная далее конфигурация - другого рода. В Вашем примере приложения
связаны по общим данным. Особый случай, однако.
>Пользователь A набивает данные в свою схему/базу. Попутно он
>создаёт методы доступа к данным, оформляя их как функции и View.
>
>Пользователь B набивает данные в свою схему/базу, но подглядывает
>в данные пользователя A.
>
>Поскольку данные критичные, нужно гарантировать, что пользователь A
>не сможет отдать доступ к новым объектам никому, кроме пользователя B.
>
>В MySQL это делается просто -
>
>GRANT CREATE, INSERT, UPDATE ON SCHEMA TO A
>GRANT SELECT ON SCHEMA TO B
>
>
>Насколько я (не)понимаю, в Oracle мне придётся делать чёрт знает что. A
>не сможет даже создать новый View в SCHEMA, если SCHEMA !=
>A.
Скорее всего, нужно будет оформлять описанную выше логику в хранимые
процедуры, которые и будут использоваться для создания и модифицирования
объектов схемы пользователем A. См. "Oracle® Database Security Guide",
раздел "5 Authorization: Privileges, Roles, Profiles, and Resource
Limitations", подразделы "Procedure Privileges", "Procedure Execution
and Security Domains", "Definer's Rights", "Invoker's Rights".
