This seems like a fairly obvious question, but I haven\'t been able to think of the proper term for what I am trying to ask, so coming up with reference material for this ha
You are correct. Basically SQL will attempt to find the field you are looking for "my_column" in all of the tables in your FROM and JOIN sections. If however you happen to have a "my_column" in table A and in table B then you need to explicitly tell it which "my_column" you are looking for by including the table name. This goes on up the chain to dbo and databasename if you have collisions there as well.
Most of the time you will find that people don't explicitly call out the tables a column is in unless they are joining multiple tables.
For example I write my queries like this:
SELECT a.field1, b.field2
FROM tableA AS a
INNER JOIN tableB AS b ON a.id = b.a_id
WHERE a.id = 123
Here I am using the AS to alias tableA and tableB down to more readable a and b. I could have just as easily written my query like this:
SELECT tableA.field1, tableB.field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123
Or like this, if field1 and field2 are unique to there tables, but this gets a bit confusing as to where each piece of data is coming from.
SELECT field1, field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123
Pluralsight are wrong.
Given the example of a stored procedure that uses a fully qualified name that refers to objects in the same database, here are two more reasons to not fully qualify in that manner:
If you have a stored procedure that refers to an object in the same database, it will break if you rename your database.
If you were to start using Visual Studio database tools to add your database scripts to source control, you get lots of warnings to deal with
It is a good idea to understand and utilise schemas properly
While it is possible to use implict names for columns it is a poor choice from a maintainabilty aspect. I never put production code out that doesn't alias every column because, when you go back a year later to change that report or query, you really don't want to have to figure out which of the 20 tables you joined to that it is in. Further, not specifying makes the database work harder to find the column and you have coding more errors where you have column names that are the same in two tables without a reference. It is a good habit to be in to use explict references.
In most cases i would always advise to use the full address just to be safe
[databasename].[dbo].[some_table].[sometimesacolumngoeshere]
However, this is only really needed when you have multiple databases. I only ever encountered one or two issues selecting databases and this is usually fixed by selecting the correct one in sql server.
Once you are actually inside a query and you have given the table a shortened alias then there really is no need to include the full address because this is already referenced.
E.G
FROM [databasename].[dbo].[some_table].[sometimesacolumngoeshere] SOME
SELECT SOME.Name
Objects can be referred through a single or several identifiers.
You can use a single identifier to refer to a object, but if the identifier is ambiguous, you must use more identifiers to uniquely identify the object.
For example, two tables named TableA
existing in different schemas must be referenced in the a query using at least a two identifiers, schema_one.TableA
and schema_two.TableA
.
There's a MDSN page where you can find out more about object names and identifiers.
Regarding the use of several identifiers for object names, if you are more specific, you reduce ambiguity in queries and speed up the parsing of the query, as the database engine doesn't have to resolve ambiguity problems, at the cost of readability of the queries.
My personal preference (for the most commonly used objects) is using schema.Table
when referencing tables and column
, if a single table is referenced in the query, and table.column
if multiple tables are referenced in the query.
SQL Server has four part names:
Most often you reference an object by name
SELECT * FROM MyTable
Then you can specify the owner or schema of the object:
SELECT * FROM dbo.MyTable
Then you can reference the database that the object lives in:
SELECT * FROM master.dbo.MyTble
Finally you can reference the table on a different server
SELECT * FROM test1.master.dbo.MyTable
It's explained better than I can on MSDN