How should I interpret “Select Distinct aliasRefForMe.field1 From a.b@a.c.d aliasRefForMe”

Question

Oracle schema table reference a.b@c.d.e aliasRefForMe - what is this?

Not sure what this means for an Oracle select statement. Anybody know?

Answer 1

The '@' is a dblink in oracle

The format of which is:

schema.schema_object@global_database_name

Answer 2

The Oracle documentation includes a section on Syntax for Schema Objects and Parts in SQL Statements.

where:

• object is the name of the object.
• schema is the schema containing the object...
• part is a part of the object. This identifier lets you refer to a part of a schema object, such as a column or a partition of a table...
• dblink applies only when you are using the Oracle Database distributed functionality. This is the name of the database containing the object. The dblink qualifier lets you refer to an object in a database other than your local database...

So in your example

Select Distinct aliasRefForMe.field1 From a.b@a.c.d aliasRefForMe

• @a.c.d is a database link, where the a part is the remote database name and the c.d is the database domain - possibly either a machine name and/or your company domain. Read more about database links and global database names and how they are formed.

• a is the name of a schema on the remote database the link is pointing to.

• b is the name of a table in that schema on the remote database.

• aliasRefForMe is a table alias (or correlation name), which is just to make it easier to refer to that table elsewhere in your query.

• field1 is the name of a column in that table on the remote database.

Without the table alias the query would be:

Select Distinct a.b.field1@a.c.d From a.b@a.c.d

... which in this contrived example is actually shorter, but with real object names would be longer than the original, and harder to read and understand. Although in this case, with only a single table being queried, you could get away with just:

Select Distinct field1 From a.b@a.c.d

as there is no ambiguity about where field1 is coming from; but qualifying everything is a good habit as it saves time and confusion later.

Table aliases are even more useful when there are multiple tables with long names - they make both the select list and join conditions shorter. It helps if the aliases are meaningful names though.