Когда следует использовать синонимы базы данных?

Question

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

Answer 1

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

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

Answer 2

Ознакомьтесь с документацией Oracle по синонимам .

В дополнение к другим ответам здесь они также обычно используются для:

• Предоставление простых в использовании имен для удаленных таблиц, т. Е. По ссылкам на базы данных
• Таблицы, которые должны быть доступны всем пользователям, т. Е. Общедоступные синонимы

Answer 3

Обычно я вижу синонимы, используемые, когда администратор БД желает разделить объекты базы данных на разные схемы, но хочет / нуждается в том, чтобы некоторые из этих объектов были видны другим схемам (но не хочет предоставлять к ним прямой доступ).

Пример, который я видел совсем недавно: несколько веб-приложений, запущенных одной и той же компанией. Пользователи обычно имеют доступ к более чем одному из этих приложений, и у них будет только одна учетная запись для доступа к этим приложениям. Информация об учетной записи пользователя хранится в схеме USER_ACCOUNTS, а все остальные приложения находятся в своих собственных схемах и получают доступ к схеме USER_ACCOUNTS через синонимы.

Answer 4

Если у вас есть имена объектов базы данных, жестко запрограммированные в существующем коде.

Использование синонимов может избавить вас от необходимости переписывать старый код, иногда из нескольких источников, который имеет свои собственные представления об именах таблиц или баз данных.

Я видел, например, код, который был написан для какого-либо производственного сервера. Кодер удобно жестко запрограммировал имя основного стола test_data, которое отлично работало на его рабочей станции. Использование синонимов вместо переписывания кода вернуло меня домой рано.

Answer 5

Как правило, встраивание имен схем в SQL или PL * SQL является плохой практикой. Поэтому, если вы пишете какой-то код, который должен ссылаться на таблицу в другой схеме, например: «выбрать идентификатор из OtherSchema.OtherTable», лучше всего определить синоним для таблицы (создать синоним OtherTable для OtherSchema.OtherTable) и написать «выбрать идентификатор» из OtherTable ".

Таким образом, если OtherTable перемещается на другое имя схемы или у вас есть другая другая установка системы, которая использует другое имя схемы, вы можете просто переопределить синонимы вместо изменения кода.

Его также можно использовать для переключения кода между двумя схемами с одинаковой структурой путем переопределения синонимов.

Answer 6

Скажем, когда вам нужно создать плохо написанное приложение (которое не выдает ALTER SESSION SET CURRENT_SCHEMA) для работы с другой схемой.

Синонимы в основном используются в качестве обходного пути для подобных случаев. С правильно написанным приложением вам вряд ли когда-нибудь придется их использовать.