The first logical component of a typical SQL SELECT statement is the FROM clause. In a simple SQL SELECT statement, the FROM clause contains a single table. However, the FROM
clause can also combine data from multiple sources and multiple types
of data sources. The maximum number of tables that may be accessed
within a single SQL SELECT statement is 256.
The FROM clause is the foundation of the rest of the SQL statement. For a table column to be in the output, accessed in the WHERE conditions, or in the ORDER BY, it must be in the FROM clause.
Possible Data Sources
SQL is extremely flexible and can accept data from 10 distinctly different types of data sources within the FROM clause:
- Local SQL Server tables.
- Subqueries serving as derived tables, also called subselects or in-line views . Common table expressions (CTEs) are functionally
similar to subqueries but may be referenced multiple times within the
query.
- You can reference views or stored SELECT statements within the FROM clause.
- Table-valued user-defined functions return rows and columns.
- Distributed data sources pull in data from other SQL Server
databases, other SQL Servers, other database platforms (for example,
Microsoft Access, Oracle, and Foxpro), or applications (for example,
Excel) using openquery() and other distributed functions.
- Full-text search can return data sets with information about which rows contain certain words.
- Pivot creates a crosstab within the FROM clause .
- XML data sources using XQuery.
- Row constructors build hard-coded rows using the values() clause.
- Inserted and deleted virtual tables from an insert, update, or delete can be passed to an outer query in the form of a subquery using the output clause.
Table Aliases
You can assign a data source a table alias within the FROM
clause. When the data source has an alias, you must refer to it by this
new name. In some cases the data source must have an alias. The
following code accesses the Person table but refers to it within the query as table P:
-- From Table [AS] Table Alias
USE AdventureWorks;
SELECT
P.LastName,P.FirstName
FROM Person.Person AS P;
In some cases the data source must have an alias.
For example, when writing a query that has a subquery as the source,
you must specify an alias. The following code accesses a subquery that
has an alias of SQ.
--From Subquery [AS] Alias
USE AdventureWorks
SELECT
SQL.LastName, SQL.FirstName
FROM
(
SELECT LastName, FirstName from Person.Person
) AS SQL;
Best Practice
Using the keyword AS to assign an
alias to a column or data source is optional and is commonly ignored.
However, this practice leads to errors in the query, as seen regularly
in SQL Server newsgroups. As a rule, always include the AS keyword.
Note
In SQL, the USE command specifies the current database. It's the code version of selecting a database from the toolbar in Management Studio.
[Table Name]
If the name of a database object, such
as a table or column name, conflicts with a SQL reserved keyword, you
can let SQL know that it's the name of an object by placing it inside
square brackets. The square brackets are specific to SQL Server and not
part of the ANSI SQL standard. For example, if you have a database
(DB1) that contains a table named [Order] you would be required to
place the table name inside square brackets. The following code
illustrates this:
USE DB1;
SELECT OrderID, OrderDate
FROM [Order];
Although it's an incredibly poor practice to
include spaces within the names of database objects, it is possible
nevertheless. If this is the case, square brackets are required when
specifying the database object. Again, assuming you work in database
DB1 and it contains a table name Order Details, you would query the
table using the following code:
USE DB1;
SELECT OrderID, ProductID, Quantity
FROM [Order Details];
Caution
The collation of the database determines
its character set and sort order, but it can also affect object names
within SQL statements. If the collation is case-sensitive, then the
object names must be case-sensitive as well. For example, with a
case-sensitive collation, a table created with the name Person is different from person or PERSON.
As a result, when referencing these objects in queries, you must adhere
to any case-sensitivity specified for that object name.
Fully Qualified Names
The full and proper name for a table is not just the table name but a fully qualified name, sometimes informally referred to as the four-part name:
Server.Database.Schema.Table
If the table is in the current database, then the
server and database name are not required, so when SQL Server
developers talk about a qualified table name, they usually mean a
two-part table name:
Schema.Table
Best Practice
Using the two-part name, (that is, the
schema and object name) is sufficient and the best practice. Including
the server and database name would restrict moving code from one server
to another (for example, from development to production). The following
code shows an example of using a two-part name:
USE DB1;
SELECT * FROM dbo.[Order]
In addition to writing cleaner code, using the qualified name has two specific benefits:
- The same table may exist in multiple schemas. If this is the case,
then the schema selected is based on the user's default schema.
Qualifying the name avoids accidentally using the wrong table.
- Qualified table names are required for the Query Engine to reuse the query execution plan, which is important for performance.
