Не е необичайно да искате да имате един скрипт за внедряване на промяна. Работата е там, че такъв скрипт трябва да се изпълнява от опитен потребител, защото трябва да има системни привилегии на ВСЯКО ниво. Това обикновено означава акаунт на DBA, за предпочитане акаунт на приложение, но иначе SYSTEM или SYS.
Така че скриптът, който искате, ще изглежда така:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
Често срещан сценарий е, че имаме набор от отделни скриптове, които са написани да се изпълняват от различни потребители, но които сега трябва да обединим в едно внедряване. Оригиналните скриптове не съдържат имената на схемите и има много добри причини, поради които не бихме искали да ги кодираме твърдо в скриптовете.
Един от начините за изграждане на този главен скрипт е да използвате промяна на синтаксиса на CURRENT_SCHEMA:
alter session set current_schema=USER_A
/
@run_grants_to_userb.sql
alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql
Все още се нуждаем от потребител на DBA, за да изпълним главния скрипт. Едно предимство на превключването на текущата схема е, че ни позволява да внедряваме обекти като връзки към бази данни, които поради странност на синтаксиса не могат да имат името на схемата в тяхната декларация. Една грешка е, че потребителят не се променя, така че скрипт, който използва псевдо-колоната USER, може да доведе до нежелани резултати.
