When should database synonyms be used?

Question

I've got the syntax down but I'm wondering if somebody can provide an illustrative use case where database synonyms are very useful.

Answer 1

It is excellent for staging mock tables when testing. For example, if your source tables contain millions of records and you want to test a small subset of data, you can use synonyms to re-direct the source table to a smaller table you control so you can stage various scenarios.

In this way, you can update/delete the data in the mock table without affecting your source table. When you are ready to use the source table, all you need to do is re-direct the synonym.

Answer 2

Check out the Oracle documentation on synonyms.

In addition to the other answers here, they are also commonly used for:

• Providing easy to use names for remote tables, i.e. over database links
• Tables that you need to be accessible to all users, i.e. public synonyms

Answer 3

I usually see synonyms used when the DBA wishes to separate database objects into different schemas, but wants/needs some of these objects to be visible to other schemas (but doesn't want to give direct access to them).

An example I've seen most recently: Several web apps run by the same company. Users usually have access to more than one of these apps, and the will only have one user account to access these apps. User-account information is stored in a USER_ACCOUNTS schema, and all other apps are in their own schemas and access the USER_ACCOUNTS schema via synonyms.

Answer 4

When you have database object names hard-coded within existing code.

Using synonyms might spare you the agony of rewriting old code, sometimes from multiple sources, which has its own ideas of the table or database names.

I have seen, for example, a code which was written for some production server. The coder has conveniently hard-coded the main table's name is test_data, which worked fine on his workstation. Using synonyms rather than rewriting his code got me home early.

Answer 5

Say, when you need to make a poorly written application (that does not issue ALTER SESSION SET CURRENT_SCHEMA) to work against another schema.

The synonyms are mainly used as a workaround for cases like that. With a properly written application, you will hardly ever have to use them.

Answer 6

In general, it is bad practice to embed schema names in SQL or PL*SQL. So if you are writing some code that must refer to a table in another schema like: "select id from OtherSchema.OtherTable" you are best off defining a synonym for the table (create synonym OtherTable for OtherSchema.OtherTable) and writing "select id from OtherTable".

This way, if OtherTable moves to a different schema name, or you have another another installation of the system that uses a different schema name you can just redefine the synonyms instead of changing the code.

It can also be used to switch your code between two schemas with the same structure by redefining the synonyms.