Как мне скрыть свою таблицу Oracle?

Нет простого способа сделать это.

Один из подходов был бы политическим: организовать проверку кода, возможно, с автоматическим поиском в кодовой базе, и просто хлопать по запястьям, когда люди делают это.

Архитектурный подход будет похож на вашу структуру из трех схем, но с небольшим отличием: схема в середине использует представления. Таким образом, схема ABC владеет таблицами и предоставляет разрешения на них схеме XYZ. Схема XYZ создает простые представления для этих таблиц (SELECT *, без предложений WHERE) и предоставляет разрешения на представления для схемы DEF. Схема DEF может выбирать только из объектов XYZ.

Конечно, все эти усилия все равно не помешают разработчикам написать код SELECT * FROM xyz.whatever. В этом случае я отсылаю вас к моему первому предложению 8-)

На самом деле есть один, действительно очень злой способ сделать это. Используйте синонимы в схеме взаимодействия с приложением (DEF), а затем измените имя схемы владения данными (ABC).

Конечно, вы должны использовать эту уловку только в том случае, если ваши сценарии установки полностью параметризованы, без собственных жестко закодированных имен схем.

Вам действительно нужно выдать ошибку? Или вам просто нужно убедиться, что приложение не использует полные имена (например, ABC.TRN)?

Предполагая, что вы просто заинтересованы в том, чтобы убедиться, что приложение не использует полные имена и что выдача ошибки была просто механизмом, о котором вы подумали, чтобы уведомить вас, вы, вероятно, можете проверить код, запросив V$SQL во время работы приложения. V$SQL перечисляет все операторы SQL в общем пуле в Oracle. Если вы регулярно запрашиваете эту таблицу во время работы приложения, вы увидите все операторы SQL, которые оно выдает. Затем вы можете регистрировать любые операторы, в которых используются полные имена.

Например

CREATE OR PROCEDURE look_for_abc_trn
AS
BEGIN
  FOR x IN (SELECT *
              FROM v$sql
             WHERE upper(sql_fulltext) LIKE '%ABC.TRN%')
  LOOP
    INSERT INTO log_of_bad_sql( sql_fulltext, <<other columns>> )
      VALUES( x.sql_fulltext, <<other columns>> );
  END LOOP;
END;

Если вы запускаете эту процедуру каждые несколько минут во время работы вашего приложения, вы увидите любой SQL, использующий полное имя, и зарегистрируете этот оператор в таблице LOG_OF_BAD_SQL. Каждые несколько минут, вероятно, излишни для хорошо написанной системы, вам просто нужно убедиться, что она запускается чаще, чем запросы устаревают из общего пула. Если у вас есть приложение, которое не использует переменные связывания должным образом, это может потребоваться каждые несколько минут, чтобы ничего не пропустить.

Как насчет ALTER SESSION?

         ALTER SESSION SET CURRENT_SCHEMA = schema

Это позволит вам войти в систему как пользователь, которому были предоставлены права выбора для таблицы, принадлежащей схеме X, и выполнить SP, который изменяет сеанс на схему X. Внешний код не узнает, что это произошло. .

Однако, если в коде внешнего интерфейса указана схема X:

           select * from X.tableName

Я не думаю, что это вызовет ошибку.

Возможно, вы могли бы объяснить, почему важно, чтобы клиентский код получал ошибку при использовании правильного имени текущей схемы?

Можно ли создать новую схему, передать права собственности на объекты старой схемы, а затем удалить старую схему, а затем использовать подход, описанный выше?

P.S. См. триггеры ПОСЛЕ ВХОДА: http://psoug.org/reference/system_trigger.html.

П.П.С. Поскольку вы подробно изложили свои требования:

... таблица может быть синонимом, использующим ссылку на базу данных, или таблица может размещаться в нескольких схемах, каждая из которых предназначена для разных выпусков. Это должно быть предоставлено базе данных для определения фактического местоположения объекта, на который ссылается клиентское приложение.

Если расположение объекта находится не в CURRENT_SCHEMA, а в какой-либо другой схеме, обе из которых имеют таблицы с именем CUSTOMER, например, механизм базы данных не будет знать, что оператор, отправленный ему клиентским приложением, должен ссылаться другая схема, если имя таблицы не определено таким образом. Это подразумевает уровень метазнаний, которого нет у движка, хотя он дает разработчику инструменты для создания такого интеллекта в виде хранимых процедур и триггеров, а также предоставления/отмены контроля над объектами.

Ваши лучшие шансы на успех в размещении этого интеллекта в серверной части будут состоять в том, чтобы отозвать все прямые права на таблицы и представления и потребовать, чтобы клиентские приложения обращались к объектам через хранимые процедуры, потому что механизм базы данных сам по себе не знает о таких вещах, как выпуск приложения. уровни. Я не вижу чисто ДЕКЛАРАТИВНОГО способа сделать это. В значительной степени это должно быть процедурным. Ваша собственная внутренняя логика должна была бы взять на себя ответственность за арбитраж между объектами с одним и тем же именем в разных схемах. Тем не менее, такие функции, как триггеры AFTER LOGON и ALTER SCHEMA, должны оказаться полезными для вас.

Вы не можете этого сделать. Синонимы — это не что иное, как указатели на объекты других схем. Вы предоставляете доступ к фактическому объекту, а не к синониму. Из документов Oracle:

http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views003.htm

Сами по себе синонимы не защищены. Когда вы предоставляете объектные привилегии синониму, вы действительно предоставляете привилегии базовому объекту, а синоним действует только как псевдоним для объекта в операторе GRANT.