Ця відповідь не визначає різниці між власником і схемою, але я думаю, що це додає до дискусії.
Я боровся з ідеєю, що я створю N кількість користувачів, де я хочу, щоб кожен із цих користувачів "споживав" (він же використовував) одну схему.
У нього є другий "синонімічний" підхід (тут не вказано). Я цитую лише версію CURRENT_SCHEMA (один із його підходів) тут:
CURRENT_SCHEMA Підхід
Цей метод використовує CURRENT_SCHEMAатрибут сеансу, щоб автоматично вказувати користувачів програми на правильну схему.
Спочатку ми створюємо власника схеми та користувача програми.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Зауважте, що користувач програми може підключатися, але не має жодних квот або привілеїв для створення об’єктів.
Далі ми створюємо деякі ролі, щоб дозволити доступ для читання, запису та доступу лише для читання.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
Ми хочемо надати користувачеві програми додаток для читання-запису на доступ до об'єктів схеми, тому ми надаємо відповідну роль.
GRANT schema_rw_role TO app_user;
Нам потрібно переконатися, що користувач програми має свою схему за замовчуванням, що вказує на власника схеми, тому ми створюємо ПІСЛЯ ЛОГОНУ, що робить це для нас.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Тепер ми готові створити об’єкт у власнику схеми.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Зверніть увагу, як надаються пільги відповідним ролям. Без цього об’єкти не були б видимі користувачеві програми. Зараз у нас є діючий власник схеми та користувач програми.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Цей метод ідеальний, коли користувач програми є просто альтернативною точкою входу до основної схеми, не вимагаючи власних об'єктів.