Подтвердить что ты не робот

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

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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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