Bukan hal yang aneh jika ingin memiliki satu skrip untuk menerapkan perubahan. Masalahnya, skrip seperti itu perlu dijalankan oleh pengguna yang kuat, karena harus memiliki hak istimewa sistem di level APAPUN. Ini biasanya berarti akun DBA, lebih disukai akun aplikasi tetapi sebaliknya SYSTEM atau SYS.
Jadi skrip yang Anda inginkan akan terlihat seperti ini:
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
/
Skenario umum adalah bahwa kami memiliki serangkaian skrip individual yang telah ditulis untuk dijalankan oleh pengguna yang berbeda tetapi sekarang kami perlu menggabungkannya menjadi satu penerapan. Skrip asli tidak berisi nama skema, dan ada banyak alasan bagus mengapa kami tidak ingin membuat hardcode dalam skrip.
Salah satu cara untuk membuat skrip master tersebut adalah dengan menggunakan ubah sintaks 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
Kami masih membutuhkan pengguna DBA untuk menjalankan skrip master. Salah satu keuntungan beralih skema saat ini adalah memungkinkan kita untuk menyebarkan objek seperti tautan basis data, yang melalui kekhasan sintaks tidak dapat memiliki nama skema dalam deklarasinya. Salah satu masalahnya adalah bahwa pengguna tidak berubah, jadi skrip yang menggunakan kolom semu USER dapat menghasilkan hasil yang tidak diinginkan.
