Es ist nicht ungewöhnlich, dass Sie ein einzelnes Skript haben möchten, um eine Änderung bereitzustellen. Die Sache ist, dass ein solches Skript von einem Hauptbenutzer ausgeführt werden muss, da es Systemrechte auf der Ebene ANY haben muss. Dies bedeutet normalerweise ein DBA-Konto, vorzugsweise ein Anwendungskonto, ansonsten SYSTEM oder SYS.
Das gewünschte Skript würde also so aussehen:
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
/
Ein häufiges Szenario ist, dass wir eine Reihe von einzelnen Skripts haben, die geschrieben wurden, um von verschiedenen Benutzern ausgeführt zu werden, die wir aber jetzt in einer einzigen Bereitstellung bündeln müssen. Die ursprünglichen Skripte enthalten keine Schemanamen, und es gibt viele gute Gründe, warum wir sie nicht in den Skripten fest codieren möchten.
Eine Möglichkeit, dieses Masterskript zu erstellen, besteht darin, die CURRENT_SCHEMA-Syntax zu ändern:
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
Wir brauchen noch einen DBA-Benutzer, um das Master-Skript auszuführen. Ein Vorteil des Wechselns des aktuellen Schemas besteht darin, dass wir Objekte wie Datenbankverknüpfungen bereitstellen können, die aufgrund einer Eigenart der Syntax den Schemanamen nicht in ihrer Deklaration enthalten können. Ein Problem besteht darin, dass sich der Benutzer nicht ändert, sodass ein Skript, das die Pseudospalte USER verwendet, unerwünschte Ergebnisse erzeugen kann.
