テスト時のモックテーブルのステージングに最適です。たとえば、ソーステーブルに数百万のレコードが含まれていて、データの小さなサブセットをテストする場合は、シノニムを使用して、ソーステーブルを自分が制御する小さなテーブルにリダイレクトし、さまざまなシナリオをステージングできます。
このようにして、ソーステーブルに影響を与えることなく、モックテーブルのデータを更新/削除できます。ソーステーブルを使用する準備ができたら、シノニムをリダイレクトするだけです。
類義語に関するOracleのドキュメント を確認してください。
ここでの他の回答に加えて、それらは一般的に次の場合にも使用されます。
- リモートテーブルの使いやすい名前、つまりデータベースリンクを介した名前の提供
- すべてのユーザーがアクセスできるようにする必要があるテーブル、つまりパブリックシノニム
私は通常、DBAがデータベースオブジェクトを異なるスキーマに分離したいが、これらのオブジェクトの一部を他のスキーマから見えるようにしたい（ただし、それらに直接アクセスしたくない）ときに使用される同義語を確認します。
最近見た例：同じ会社が実行するいくつかのWebアプリ。ユーザーは通常、これらのアプリの複数にアクセスでき、これらのアプリにアクセスするユーザーアカウントは1つだけです。ユーザーアカウント情報はUSER_ACCOUNTSスキーマに保存され、他のすべてのアプリは独自のスキーマにあり、類義語を介してUSER_ACCOUNTSスキーマにアクセスします。
既存のコード内にハードコードされたデータベースオブジェクト名がある場合。
シノニムを使用すると、古いコードを書き換える手間を省くことができます。時には、複数のソースから、テーブルまたはデータベース名の独自のアイデアを持っています。
たとえば、いくつかの本番サーバー用に作成されたコードを見たことがあります。コーダーは、メインテーブルの名前がtest_data、それは彼のワークステーションでうまくいきました。彼のコードを書き直すのではなく、同義語を使用すると、私は早く帰宅しました。
一般に、SQLまたはPL * SQLにスキーマ名を埋め込むことはお勧めできません。したがって、「select id from OtherSchema.OtherTable」のような別のスキーマのテーブルを参照する必要があるコードを記述する場合は、テーブルのシノニムを定義し（OtherSchema.OtherTableのシノニムOtherTableを作成）、「select id OtherTableから」。
このように、OtherTableが別のスキーマ名に移動した場合、または別のスキーマ名を使用する別のシステムがインストールされている場合は、コードを変更する代わりに同義語を再定義するだけで済みます。
また、シノニムを再定義することで、同じ構造を持つ2つのスキーマ間でコードを切り替えることもできます。
たとえば、別のスキーマに対して動作するように（ALTER SESSION SET CURRENT_SCHEMAを発行しない）不十分なアプリケーションを作成する必要があるとします。
同義語は、主にそのような場合の回避策として使用されます。適切に作成されたアプリケーションがあれば、それらを使用する必要はほとんどありません。