Querying SQL Server: Run T-SQL operations, data extraction, data manipulation, and custom queries to deliver simplified analytics (English Edition)

CHAPTER 1

Writing Basic SQL Queries

Welcome to SQL Server and the new world of data and analytics that you are about to experience. As you are standing on the threshold of this voyage into the realms of databases and data analysis, you could be feeling a little apprehensive. Well, don’t worry, your journey will be as simple and comprehensible as I can make it. This chapter will start you on your adventure first by outlining the software that you need to install and then by explaining what a database is. Then I will show you how to look at the data itself. As you progress, you will learn how to be more selective about the data that you analyze.

Prerequisites

It may seem obvious, but you will need some data in an accessible database before you can start your analysis. So, throughout this book I will be asking you to develop your analytical skills with the aid of a sample database named PrestigeCars. This database contains a small amount of data concerning sales of vehicles by a fictitious British car reseller. If you want to try the examples in this chapter, you will have to download the sample database from the TetrasPublishing website (www.tetraspublishing.com/sqlserver) and install the database into a version of SQL Server. So, it follows that now could be a good time to set up the sample database as described in Appendix C, unless you have already done so. Of course, you can install the sample database only if you have a version of SQL Server already installed and available. So, if you are not in an enterprise environment where SQL Server is already accessible, you will need to install a version of the database software before anything else. This is described in Appendix A.

Once SQL Server is up and running, you will need somewhere to enter and run your queries. I am presuming that you have also installed SQL Server Management Studio (SSMS) as the interface to the sample database. Installing this piece of software is also described in Appendix B. I presume that you will be trying your queries using this particular application.

SSMS is not the only tool that you can use to query databases. There are indeed many excellent applications that you can use to analyze SQL Server data. So, if you prefer to use another application to test the queries in this book, then that is entirely up to you. However, you will have to handle the specifics of installing and working with that application yourself; there are simply too many of them for us to explain every one!

Whatever the tool that you use to write your queries, this chapter will teach you how to

Query SQL Server databases using SQL Server Management Studio

List the contents of tables

Select only certain fields in tables to display

Display only a few records from a table

Give columns new names in your query output

Sort your output

When you have all the prerequisites in place, it is time to move on to the core focus of this chapter and start querying SQL Server data.

Note: If you know a little about the standard Microsoft data tools and if you have a basic knowledge of databases, then feel free to skip past the first few sections of this chapter until you find the parts that are new to you. However, I realize that the first steps for a novice are important. Consequently, I prefer to start from the beginning and provide all the information that you are likely to need to get the most out of your SQL learning experience.

1.1 Relational Databases

As you have decided to learn to analyze data using SQL queries, you need to know a few basic concepts to begin with.

To start, what is a relational database (or a relational database management system, RDBMS)? At its simplest, a relational database is a method of storing data in a clearly defined way. A database consists of tables (sometimes thousands of tables) that each contain rows of data. All the rows in a table consist of the same number of columns. So, a table is really nothing more than a well-structured list—rather like the ones that you have probably encountered in Excel.

In a well-designed database, tables will be organized to avoid duplicating data. The tables in the database can then be linked together to present the data in different ways.

To resume, then, a relational database is a collection of lists (tables) containing columns (fields) of data in a set of rows (records). These elements can then be accessed independently or joined together to deliver the analysis you are looking for.

Conceptually, a database looks something like Figure 1.1.

Figure 1.1: Conceptualizing a relational database

Note: Please note that all the exercises in this book use a sample database named PrestigeCars. If you need to install this database, then please consult Appendix C.

1.2 Running SQL Server Management Studio

The time has come to start putting the theory into practice. As relational databases can require considerable IT horsepower, they will nearly always reside on powerful servers either on-premises or in the cloud. They are rarely installed on PCs or laptops unless they are being used for learning.

So, what you will nearly always do is connect to the database using a separate piece of software that is, itself, installed on a PC. This is called a client-server model, where you use one application (the client) to connect to the database (the server). While there are many applications that can read data from SQL Server databases, there is one that tends to be used by most analysts and developers. This is SQL Server Management Studio. It is an application written by Microsoft and is (at least at the time that this book went to press) free to install and use. As befits a piece of software that has been evolving for about 20 years, it is both efficient and reliable. Indeed, it is the standard tool that is used by hundreds of thousands of analysts and developers. Consequently, this is the tool that I will be using throughout this book.

I will assume that you have SSMS installed on your PC. If this is not the case, then please consult Appendix B to learn how to find and install this tool.

To connect to a SQL Server database, follow these steps:

Double-click the SQL Server Management Studio icon on the desktop, in the taskbar, or in the list of apps.

SQL Server Management Studio opens and displays the Connect to Server dialog with the server details, as you can see in Figure 1.2.

Figure 1.2: The SQL Server Management Studio Connect to Server dialog

Select the server name from the pop-up list. If you are in an enterprise environment, you can always ask a system administrator which database to use. If you have just installed a stand-alone version of SQL Server on your laptop or workstation (this is described in Appendix A), then just enter Localhost in the Server Name popup.

Click Connect. You will see SQL Server Management Studio, ready for you to begin working, as shown in Figure 1.3.

Figure 1.3: SQL Server Management Studio

Expand the Databases folder on the left. (You do this by clicking the small plus [+] symbol to the left of the folder.) You will see all the databases that are available for you to work with. If this is a new installation of SQL Server, you will not see any database names except for the PrestigeCars database that you installed following the instructions in Appendix C.

Expand the PrestigeCars database in the list by clicking the plus symbol to the left of the database folder. You will then see all the database folders, as shown in Figure 1.4.

Figure 1.4: The PrestigeCars database

Click the PrestigeCars database on the left (this window is known as the Object Explorer).

Click the New Query button in the SQL Server Management Studio toolbar at the top of the screen. A new query window opens on the right of the Object Explorer window. You should see something like Figure 1.5.

Figure 1.5: SQL Server Management Studio ready for querying

Now that you have connected to the database, you are ready to start analyzing the data it contains. I realize that the first time you carry out this sequence of instructions the process may seem a little laborious. However, you will probably launch SQL Server Management Studio only a couple of times a day when you start working with SQL Server. So, it is not really any different than opening Microsoft Word or Excel when you first start creating documents or editing spreadsheets. In any case, this routine will certainly become second nature in a short time.

1.3 Displaying the Tables in a Database

All the data in a SQL Server database is stored in tables. A database can consist of dozens—or even hundreds—of tables of data that have been carefully designed and created by database professionals. The first thing that you will have to do when faced with any database that is new to you is to take a look at the tables it contains. To do this, follow these steps:

Expand the Tables folder by clicking the small plus symbol to the left of the Tables folder in the PrestigeCars database. You should see something like the list of tables shown in Figure 1.6.

Figure 1.6: Displaying the tables contained in a database

As this sample database is small, it contains only a handful of tables. You will learn what they all contain as you progress through this book.

1.4 Finding All the Views in a Database

SQL databases do not just contain tables. Indeed, they can contain hundreds of different items (that are collectively called objects). One of the aims of this book is to introduce you progressively to the essential objects that you will need to learn to manipulate when querying data.

Apart from tables, one kind of object that you need to know about is the view. Quite simply, although all data is stored in tables, you could frequently find yourself querying not only tables but views too. This is because views are a way of looking at data that filter or combine data in some way, essentially making life easier for users by doing some of the work for you.

In SQL queries you can treat views exactly as if they were tables. The first thing to know is how to find the views in a database. Fortunately, this is similar to what you just did when looking at the database tables.

Expand the Views folder by clicking the small plus symbol to the left of the Views folder in the PrestigeCars database. You should see something like the list of views in Figure 1.7.

Figure 1.7: Displaying the views contained in a database

As you can see, there are even fewer views than tables in the PrestigeCars database. Indeed, there is only a single view named SalesByCountry.

1.5 Schemas

If you take a close look at the tables and views in the PrestigeCars database, you can see that each has a name in two parts. First, there is a shared name (almost like a family name) such as Data or Reference. Then there is there is a period and finally the actual unique name of the table or view. This naming style exists because data can get complicated. Specifically, if you are dealing with thousands of tables and views in a database, you will need to find ways of organizing the elements. One technique is to group tables into schemas. A schema is a kind of virtual folder that lets you place together tables and views that you want to consider as sharing common traits. If you prefer, you could consider schemas as a kind of color-coding to group items to suit your needs.

Using a schema is not compulsory, but schemas let you apply a common focus to otherwise disparate elements. As you can see in Figure 1.5, all the tables and views that are in the same schemas are grouped together.

As you will see (beginning with the next section), schemas are an essential part of the table or view name. Indeed, when you use a table or view in a piece of SQL code, you should always include the schema name and a period before the table name. If you like, you could consider this to be something similar to referring to a person by their last name and first name to avoid confusing them with someone else.

There will always be at least one schema in SQL Server—the dbo schema. However, as this schema is always present, SQL Server calls it the default schema, and you do not need to use it when referring to tables in the dbo schema—just use the table name on its own. However, I have made sure that all the tables and views in the PrestigeCars database are in specific schemas to ensure that you learn good SQL habits from the outset.

1.6 Displaying the Data in a Table

Now that you have learned how to look inside a database, it is time to look at some actual data. For your first query, let’s suppose you want to see what makes of vehicle are sold by Prestige Cars Ltd.

Click the PrestigeCars database in the Object Explorer (the left window) in SQL Server Management Studio.

Open a new query window (unless one is already open) by clicking the New Query button in the toolbar at the top of the SSMS window.

In the query window, type in the following short piece of SQL:

SELECT  *

FROM    Data.Make

Press the F5 function key to run the code and show the results. The results will appear under the code, as shown in Figure 1.8.

Figure 1.8: Displaying all the data in a table with SELECT *

How It Works

In just five words you have said to SQL Server, Show me the complete contents of the Make table, including all the rows and all the columns of data. All you needed to know is which table you wanted to look at. SQL did the rest.

This code snippet is incredibly simple—five words in all—but that is enough to show you how SQL works in practice. If you issue the right command, then you will get back the data you want to see.

As you can see, this command did more than just list the makes of car. It also showed any other elements that are present in the table, but that is exactly the point of the command. This way you get to see everything that is stored in a table of data.

Of course, you will need to know which table contains the data you want to display when you are dealing with your own data. If you are working in an enterprise environment, this may involve talking to the people in your organization who developed or maintain the databases. Alternatively, there may be documentation that you can read to find the information you require.

If there is no one you can ask and no documentation available, then you can still acquaint yourself with the data by running the SELECT * FROM clause with each data table that you can see in the Tables folder. However, before doing this I advise you to continue a little further in this book and learn how to limit the number of records output by a query.

So, what exactly have you done here? Let’s take a closer look at what you have written. figure 1.9 breaks down the SQL statement into its constituent parts.

Figure 1.9: The anatomy of a simple SQL statement

These constituent parts are:

Tricks and Traps

This was a simple SQL command, but the following are nonetheless a few key points that you will need to remember:

As I mentioned, each SQL Server instance can contain (or host if you prefer) dozens of databases. This means you always have to tell SQL Server which database you want to interrogate. One easy way to do this is to click the appropriate database before opening a new query window, just like you did in this example.

If you do not indicate the right database to use, SQL Server will either return no data at all or, worse, return the wrong data from another database.

F5 runs (or executes if you prefer) the SQL code that you have typed or copied into a query window. There are other ways to run a query that you will learn a little later in this chapter.

It can happen (even when you are an experienced data analyst) that executing a query returns nothing more than an irritating error message like this:

Msg 208, Level 16, State 1, Line 1

Invalid object name 'Data.Make'.

This probably means you have not clicked a database name in the Object Explorer to specify which database you want to query. In this case, you can set the appropriate database by selecting it from the list of databases that appears when you click the pop-up list at the top left of the SSMS window, as shown in Figure 1.10.

Figure 1.10: Selecting a database to query

In this book I will explain the data tables that you need to use as you meet them. Here you have seen the first of the small set of tables that make up the sample database. As its name suggests, the Make table contains the makes of cars that are stocked and sold by Prestige Cars Ltd.

Note: Make sure you have not selected any of the SQL text before you execute the query. This guarantees that SSMS will run the entire SQL snippet in the query window.

1.7 Limiting the Number of Records Displayed

SQL Server tables can contain millions—or even billions—of records. Each time that you run a query, all the records you see are sent from the server to the querying application. It follows that displaying all the rows in a huge table can place an unnecessary strain on the server that stores the data as well as on the network that connects the server to your workstation. So, in the real world, it is a good idea to display only a small number of records when examining a table. This is particularly true when looking at a table for the first time.

Fortunately, SQL has a way of limiting the number of rows returned by a query. This is nothing more than a simple extension to the command that you used in the previous section. Here you can see how to tweak a piece of SQL code to display only a few makes of vehicle:

Delete any SQL that might be in the query window (or open a new query window), and enter the following code snippet:

SELECT   TOP 10 *

FROM     Data.Make

Run the SQL code by pressing F5.

How It Works

Executing this command will display all the columns in the table—but only the first ten records. As this will look like the output shown in Figure 1.3 (limited to the first ten rows), I will not waste space by repeating the results here.

You may well be wondering which records you are seeing when you ask SQL to display the TOP 10 rows (or indeed any other number or records). The answer is that you might not even see the same set of records when you run this command at different times. SQL Server does not necessarily return the first (or last) ten records that were added to a table. Neither does it display the last ten to be updated, viewed, or printed.

This apparently minor question reveals an important fact about SQL databases. They can store records in any order (unless the database programmer instructed them to do otherwise). However, there is no immediate way of telling, when you look at a table, whether the data is stored in any sequence. You need to remember this when querying tables and never trust the data to be returned in any specific order unless you have asked for this to happen. How you do this is explained later in this chapter.

Tricks and Traps

The following are a few points that I think are worth mentioning at this juncture:

There are several ways to run the SQL code in a query window. Pressing F5 is only one method. Another is to select QueryExecute from the SSMS menu. Yet another alternative is to click the Execute button (the red exclamation mark) in the toolbar.

In most cases, you can enter the keywords as well as the table and column names in either uppercase or lowercase, or even a mixture of the two. This will depend on how your SQL Server has been configured. In this book, however, I will always enter keywords in uppercase to help them stand out in the code snippet. Ideally, this will make them easier to learn.

You do not have to write queries in a purely linear fashion, starting with the SELECT clause and continuing to the end of the query. You can start with any part of the query and build it up as you want. In practice, however, you will probably nearly always begin with the FROM clause and then move on to the SELECT clause.

SQL Writing Style

You can format the SQL you write in any way that suits you. You may prefer to write short SQL statements on a single line. Alternatively, you may find it clearer if you place the core keywords like SELECT and FROM on separate lines. The choice is yours.

All you have to remember is that keywords must be separated by a space, a tab character, or a line break. Besides that, the presentation of your SQL is entirely up to you. After all, all that really matters is that it works.

1.8 Displaying Data from a Specific Field

A SQL Server table can contain hundreds of columns. Most of the time you will want to display data from only a few of the available columns in a table. The next piece of SQL shows how you choose a single column to display instead of all the available columns in a table. More specifically, it shows how to list only the customer names.

SELECT CustomerName

FROM   Data.Customer

Executing this piece of code (using any of the techniques that I pointed out at the end of the previous section) will show you something similar to the output shown in Figure 1.11.

Figure 1.11: Choosing a column from a table

How It Works

By replacing the star (or asterisk if you prefer) in your SQL with a specific column name, you have told SQL Server that it is this column—and this column only—that you want to display. This example also makes the point that SQL is an extremely modular and extensible language, and you can easily extend or modify a simple command to make it more specific.

Of course, this approach relies on your knowing the exact name of a column and also typing it exactly as it appears in the table. Fortunately, SSMS has ways of displaying column names and using them in your SQL, as you will discover in the next section.

Tricks and Traps

Even simple SQL commands have their subtleties. When listing data, you need to remember the following:

You can write short SQL commands like this one on a single line of you prefer. That is, you could write the following instead of placing each clause on a separate line:

SELECT CustomerName FROM Data.Customer

This is entirely a question of personal choice. As I am presuming that you are new to SQL, we will keep the core SQL statements on separate lines in this book to accentuate the underlying logic of the language. In your queries, you can write the SQL any way you want, as long as it works. All that SQL Server wants is that the grammar of the command is technically accurate and that keywords are separated by spaces or returns.

1.9 Finding the Columns in a Table

You may well be wondering how on Earth you can be expected to remember all the columns in each table so that you can type them into your SQL queries. Fortunately, SQL Server Management Studio can help you here by displaying all the columns in a table in a single click.

Displaying the columns in a table is really easy.

Click the plus symbol to the left of the table whose columns you want to see (we will use the Country table in this example).

Click the plus symbol to the left of the Columns folder. You should see something like Figure 1.12.

Figure 1.12: Displaying the columns in a table

When you display the list of columns in a table, you can also see some more technical information concerning the type of data that the column contains and possibly the maximum amount of data that each column can hold. While useful, this is not really relevant to the queries that you will be creating in the first few chapters of this book.

Note: SSMS can also list columns (or fields if you prefer) as you enter SQL code. You might see this happening as you enter your SQL. I will explain this more fully in the next chapter.

1.10 Displaying Data from a Specific Set of Fields

SQL does not limit you to displaying all the fields—or only one field—from a table. You can choose not only the fields from a table that you want to display but also the order in which they will appear in the output from the query. The following piece of code shows you how to select two fields (Country Name and Sales Region) from another table in the database—the Country table:

SELECT CountryName, SalesRegion

FROM   Data.Country

Executing this piece of code will show you something similar to the output in Figure 1.13.

Figure 1.13: Displaying multiple fields from the Country table

Columns or Fields

Whereas spreadsheets prefer the term columns, databases tend to use the word fields. So, despite the fact that we have used the term column up until now in this chapter, I will switch to using the term field from now on.

Both words, however, describe the same thing and can generally be used interchangeably.

How It Works

Here again, you have extended the base SQL that you used at the start of the chapter. Specifically, you have developed the SELECT statement to include the field names containing the data that you want to view. All you had to do was to separate each field name with a comma and place the field names in the order that you want to see their data in the output from left to right.

Tricks and Traps

There is only one major trick to remember when listing a specific set of fields.

Remember not to add a comma after the final field in a list of fields in the SELECT clause.

1.11 Modifying the Field Name

Many databases have cryptic—or frankly incomprehensible—field names. While as an analyst or data guru you might get used to this, it is not always a good idea to present information to users in a way that makes the data harder to understand than is really necessary. So, SQL allows you to output the data under a different field header to enhance readability. In this example, you will display the country field under another name. Start by taking a look at the code snippet and then at the output it returns in Figure 1.14:

SELECT CountryName, CountryISO3 AS IsoCode FROM Data.Country

Figure 1.14: Changing a field name using an alias

How It Works

In the query output, the original field name is replaced by the name you have chosen—ISOCODE in this example. This technique is called aliasing; you are giving the field another name in the query. Applying an alias has no effect at all on the underlying data and does not change the underlying field name. What it does do is apply a different (and ideally more comprehensible) name in the query output.

Tricks and Traps

Aliases have their own particular set of rules that must be adhered to if they are to work correctly. Essentially you need to remember the following points:

You may have noticed that all the table and field names that have been used so far contain neither spaces nor special (that is, nonalphanumeric) characters. This is because SQL requires you to specify the names of what it calls objects—that is, fields and tables among other things—in a specific way. However, I do not want to make things appear over-complicated here, so as a starting point, let’s just say you are better avoiding all nonalphanumeric characters when creating an alias for a field.

If you want to add a space to an alias (suppose in the example used in this section you want to see ISO Code as the field heading), then you must place the alias inside square brackets or double quotes. That is, you can write either of the following to add a space to the alias ISOCode that you want to use instead of the real field name:

SELECT CountryName, CountryISO3 AS [Iso Code] FROM Data.Country

SELECT CountryName, CountryISO3 AS Iso Code FROM Data.Country

In practice, many data people advise that you avoid spaces and nonstandard characters if you can, as once you have started down this route, you will have to add the double quotes or square brackets every time you refer to this alias (or table or field) in your code, which can get painful when writing complex queries. So, we will stick to names without spaces or nonalphanumeric characters in this book.

In some queries you may find that you are faced with field names so cryptic that they are hard to read. In these cases, you could try using the underscore character instead of a space in a field name. This would give an alias that looks like Iso_Code in this example. While this is certainly a little geeky, this is nonetheless easier to read than a name without any spaces while being much easier to use in more advanced (and complex) queries.

An alias cannot be more than 128 characters long.

You can also add an alias using code like this:

SELECT CountryName, CountryISO3 = CountryISO3 FROM Data.Country

However, I prefer not to use this technique and so will not be taking this approach when aliasing columns.

Undo and Redo

SSMS is like many other desktop applications in that you can undo changes—and redo them—if you want.

Ctrl-Z will undo one or more modifications.

Ctrl-Y will redo modifications that you have undone.

1.12 Sorting Data

Now that you can select the fields that contain the data you want to see in the sequence that you want to see them, you probably also want to sort the data. For example, you might want to sort car sales by increasing sale price. To do this, just run the following snippet and take a look the numbers in the SalePrice field in Figure 1.15. They are now sorted from lowest to highest.

SELECT    *

FROM      Data.SalesByCountry

ORDER BY  SalePrice

Figure 1.15: Sorting data in descending order

How It Works

To sort the data returned by a query, just add the ORDER BY keyword (it is considered to be a single keyword even if it is really two words) after the FROM clause of the SQL command. Then you add the field that you are sorting the data on. This creates an ORDER BY clause.

Equally important is the fact that, once again, writing SQL can be all about making simple extensions to the code that you have written so far. So, you do not have to produce instant reams of code that work the first time. You can start with a small snippet of code, test it, and then extend it until it does exactly what you want it to do.

Tricks and Traps

These are several key points to remember here:

The ORDER BY keyword can also be used on text (in which case it sorts in alphabetical order), on numbers (where it sorts from lowest to highest), or on dates (in which case it places the dates in sequence).

If you want, you can add the ASC keyword after the sort field name to force an ORDER BY statement to sort the data in ascending order. However, SQL Server sorts data in ascending order out of the box. So, the result would be the same even if you wrote this:

SELECT * FROM Data.SalesByCountry ORDER BY SalePrice ASC

If you test this, you will see the same result that you saw when you added the ASC keyword to the ORDER BY clause in the SQL snippet at the start of this section. Techies refer to this as the default sort order.

If you find that reiterating field names in the ORDER BY clause is somewhat laborious, then you can always apply a shortcut. Instead of using a field name, you can use a number to represent it. So, you could write the SQL query at the start of this section as follows:

SELECT    CountryISO3 AS IsoCode, CountryName

FROM      Data.Country

ORDER BY  1

The number that you use in the ORDER BY clause stands for the position of the field in the SELECT clause of the SQL statement. So in this example 1 represents IsoCode (aliased as IsoCode). 2 would mean mean CountryName (the second field in the SELECT clause) etc.

1.13 Sorting Data in Reverse Alphabetical Order

As you saw in the previous example, data can be sorted from lowest to highest really quickly and easily. You are can also sort data from highest to lowest (or Z to A). Changing the sort order is as simple as replacing the ASC (short for ascending) keyword that you just met with the DESC (short for descending) keyword. You can see this in the output shown in Figure 1.16, which is the result of the following code snippet that sorts the country names in reverse alphabetical order of ISO code:

SELECT    CountryISO3 AS IsoCode, CountryName

FROM      Data.Country

ORDER BY  IsoCode DESC

Figure 1.16: Sorting data in alphabetical order

How It Works

Switching the sort order is as easy as adding the ASC keyword to the end of the ORDER BY clause or replacing the DESC keyword with the ASC keyword at the end of the ORDER BY clause of a SQL command. Using DESC forces SQL to sort the results from highest to lowest (if they are numbers), Z to A (if they are text), or latest to earliest (if they are dates).

1.14 Applying Multiple Sort Criteria

Larger data sets can require that you sort data according to multiple criteria. Suppose, for instance, that you want to list all the cars sold first by country, then by make (per country), and finally by model if there are several makes sold for a specific country.

This is easy to do in SQL because it is a simple extension of the techniques that you have seen in the previous two sections. Take a look at the following code snippet:

SELECT    CountryName, MakeName, ModelName

FROM      Data.SalesByCountry

ORDER BY  CountryName, MakeName, ModelName

Executing this query will return a dataset similar to the one shown in Figure 1.17.

Figure 1.17: Sorting sales using multiple fields

How It Works

Sometimes you will be faced with a table where some fields contain the same data elements repeated several times. A telephone directory is like this. You may have many pages of people named Smith, although nearly all may have different first names. Even if the last name and the first name are the same, they may have different middle initials. In these cases, you need to sort the data on successive fields so that (to continue the telephone directory analogy) you sort first by last name, then by first name, and finally by middle initial.

Entering several fields after the ORDER BY keyword tells SQL to sort the data progressively on the fields that you entered. In this example, it means the following:

First by the country

Then by the make (if there is more than one record with the same country)

Finally by the model (if there is more than one record with the same country and make)

All you have to do is enter the field names separated by a comma in the ORDER BY clause.

Tricks and Traps

Applying a multiple sort order has its own specific set of core requirements. These include the following:

While there may be technical limits to the number of fields you can sort on, in practice you do not need to worry and can extend the field list that you use in the ORDER BY statement to include many fields.

In this example, you used the same fields in the SELECT statement that you used in the ORDER BY statement. This is not compulsory in SQL because there is no obligation in a basic SQL query to display the same fields that you use for ordering the data. However, when you are testing your SQL skills (or ensuring that the data looks like you think it should), it can be a good idea to use the same groups of fields in both clauses. This way you can see whether the output is what you expect.

Sorting query results requires a lot of computing horsepower when you are dealing with large tables or small database servers. I recommend that you sort data only if it is really necessary.

As was the case for SELECT clauses, you should not add a comma after the final field name in the ORDER BY clause.

1.15 Choosing the Database to Query

Toward the beginning of this chapter you learned to expand a database in the Object Explorer window and click a database before opening a query window. This is not the only way that you can indicate to SQL Server which database you want to query.

Another way to select the database to use (which techies call setting the database context) is as follows:

Open a new query window.

In the query toolbar, click the pop-up list that contains all the available databases.

Select the database to use (PrestigeCars in this example). You can see this in Figure 1.18.

Figure 1.18: Selecting a database to query

This is all you have to do to select a database for the query that you are about to write or that you have just written.

Conclusion

This chapter showed you how to perform elementary SQL queries. You saw how to open SQL Server Management Studio and connect to a specific database. Then you saw how to dig into some of the tables that make up a database and take a look at the data they contain.

You then learned how to be a little more selective when outputting data and consequently to choose which fields to display from a query. You also saw how to limit the number of records that a query returned as well as how to sort the data.

All in all, you have already made vast strides toward the basic analysis of SQL Server data. With this knowledge safely acquired, it is time to move on to the next step: using data from multiple tables. This is what you will be looking at in the next chapter.

Core Knowledge Learned in This Chapter

SQL is a language that is built on a collection of core concepts and a set of clearly defined keywords. Using all of these correctly—and understanding exactly what they can and cannot do—is what learning to use SQL is all about. To help you build up your SQL vocabulary, we will always recapitulate any new concepts and keywords that you have met at the end of each chapter. The following are the fundamental keywords that you have learned to use in this chapter: