Я думаю, что это просто ошибка. Посмотрите на это аналогичное описание проблемы .
Отлично подходит для постановки фиктивных таблиц при тестировании. Например, если ваши исходные таблицы содержат миллионы записей и вы хотите протестировать небольшое подмножество данных, вы можете использовать синонимы, чтобы перенаправить исходную таблицу в меньшую таблицу, которой вы управляете, чтобы вы могли подготовить различные сценарии.
Таким образом, вы можете обновить / удалить данные в фиктивной таблице, не затрагивая исходную таблицу. Когда вы будете готовы использовать исходную таблицу, все, что вам нужно сделать, это перенаправить синоним.
Ознакомьтесь с документацией Oracle по синонимам .
В дополнение к другим ответам здесь, они также обычно используются для:
Если у вас есть имена объектов базы данных, жестко запрограммированные в существующем коде.
Использование синонимов может избавить вас от необходимости переписывать старый код, иногда из нескольких источников, в котором есть свои представления о названиях таблиц или баз данных.
Я видел, например, код, который был написан для какого-либо производственного сервера. Кодер удобно жестко запрограммировал имя основной таблицы test_data
, что прекрасно работало на его рабочей станции. Использование синонимов вместо того, чтобы переписывать его код, вернуло меня домой рано.
Скажем, когда вам нужно сделать плохо написанное приложение (которое не выдает ALTER SESSION SET CURRENT_SCHEMA
) для работы против другой схемы.
Синонимы в основном используются как обходной путь для подобных случаев. С правильно написанным приложением вам вряд ли когда-нибудь придется их использовать.
Вообще, встраивать имена схем в SQL или PL*SQL - плохая практика. Поэтому если вы пишете код, который должен ссылаться на таблицу в другой схеме, например: "select id from OtherSchema.OtherTable", вам лучше всего определить синоним для таблицы (создать синоним OtherTable для OtherSchema.OtherTable) и написать "select id from OtherTable".
Таким образом, если OtherTable перейдет на другое имя схемы, или у вас будет другая установка системы, которая использует другое имя схемы, вы сможете просто переопределить синонимы, а не менять код.
Это также можно использовать для переключения кода между двумя схемами с одинаковой структурой путем переопределения синонимов.
Обычно я вижу, что синонимы используются, когда DBA хочет разделить объекты базы данных по разным схемам, но хочет/не хочет, чтобы некоторые из этих объектов были видны другим схемам (но не хочет предоставлять к ним прямой доступ).
Пример, который я видел совсем недавно: Несколько веб-приложений одной компании. Пользователи обычно имеют доступ к нескольким из этих приложений, и у них есть только одна учетная запись пользователя для доступа к этим приложениям. Информация об учетной записи пользователя хранится в схеме USER_ACCOUNTS
, а все остальные приложения находятся в своих собственных схемах и обращаются к схеме USER_ACCOUNTS
через синонимы.