Nie jest niczym niezwykłym chęć posiadania jednego skryptu do wdrożenia zmiany. Chodzi o to, że taki skrypt musi być uruchamiany przez zaawansowanego użytkownika, ponieważ musi mieć uprawnienia systemowe na DOWOLNYM poziomie. Zwykle oznacza to konto DBA, najlepiej konto aplikacji, ale poza tym SYSTEM lub SYS.
Skrypt, który chcesz, wyglądałby tak:
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
/
Typowym scenariuszem jest to, że mamy zestaw pojedynczych skryptów, które zostały napisane do uruchamiania przez różnych użytkowników, ale które teraz musimy połączyć w jedno wdrożenie. Oryginalne skrypty nie zawierają nazw schematów i istnieje wiele dobrych powodów, dla których nie chcielibyśmy ich zakodować na sztywno w skryptach.
Jednym ze sposobów na zbudowanie tego głównego skryptu jest użycie zmiany składni 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
Nadal potrzebujemy użytkownika DBA, aby uruchomić skrypt główny. Jedną z zalet przełączania bieżącego schematu jest to, że pozwala nam wdrażać obiekty, takie jak łącza do baz danych, które ze względu na dziwactwo składniowe nie mogą zawierać nazwy schematu w swojej deklaracji. Jedna uwaga jest taka, że użytkownik się nie zmienia, więc skrypt wykorzystujący pseudokolumnę USER może dawać niepożądane wyniki.
