Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
4 JOINs Feel like a seasoned professional yet? Let me dash that feeling right away (just kidding)! While we now have the basic statements under our belt, they are only a small part of the bigger picture of the statements we will run. To put it simply, there is often not that much you can do with just one table — especially in a highly normalized database. A normalized database is one where the data has been broken out from larger tables into many smaller tables for the purpose of eliminating repeating data, saving space, improving performance, and increasing data integrity. It’s great stuff and vital to relational databases; however, it also means that you wind up getting your data from here, there, and everywhere. We will be looking into the concepts of normalization extensively in Chapter 8. For now, though, just keep in mind that the more normalized your database is, the more likely that you’re going to have to join multiple tables together in order to get all the data you want. In this chapter, I’m going to introduce you to the process of combining tables into one result set by using the various forms of the JOIN clause. These will include: ❑ INNER JOIN ❑ OUTER JOIN (both LEFT and RIGHT) ❑ FULL JOIN ❑ CROSS JOIN We’ll also learn that there is more than one syntax available to use for joins, and that one particular syntax is the right choice. In addition, we’ll take a look at the UNION operator, which allows us to combine the results of two queries into one. JOINs When we are operating in a normalized environment, we frequently run into situations in which not all of the information that we want is in one table. In other cases, all the information we want
- Page 68 and 69: Chapter 2: Tools of the Trade 30 lo
- Page 70 and 71: Chapter 2: Tools of the Trade 32 3.
- Page 72 and 73: Chapter 2: Tools of the Trade 34 Fi
- Page 74 and 75: Chapter 2: Tools of the Trade Figur
- Page 76 and 77: Chapter 2: Tools of the Trade Note
- Page 78 and 79: Chapter 2: Tools of the Trade bcp i
- Page 81 and 82: 3 The Foundation Statements of T-SQ
- Page 83 and 84: asic SELECT statement. Fire up the
- Page 85 and 86: Now let’s try taking a little bit
- Page 87 and 88: very few of your tables will have s
- Page 89 and 90: Operator Example Usage Effect ALL,
- Page 91 and 92: Chapter 3: The Foundation Statement
- Page 93 and 94: WHERE SalesOrderID IN (43660, 43670
- Page 95 and 96: AVG This one is for computing avera
- Page 97 and 98: efore, but remove the two AS keywor
- Page 99 and 100: You’ll get a result that is a bit
- Page 101 and 102: What if we want to place conditions
- Page 103 and 104: Let’s say, for example, that we w
- Page 105 and 106: Chapter 3: The Foundation Statement
- Page 107 and 108: City varchar(20) NOT NULL, State ch
- Page 109 and 110: for it in the INSERT statement. For
- Page 111 and 112: And sure enough, we get back the on
- Page 113 and 114: Chapter 3: The Foundation Statement
- Page 115 and 116: Chapter 3: The Foundation Statement
- Page 117: Chapter 3: The Foundation Statement
- Page 121 and 122: Now let’s see what happens when w
- Page 123 and 124: We can figure out which BusinessEnt
- Page 125 and 126: Be aware that using an alias is an
- Page 127 and 128: Person.Person Sales.Customer Busine
- Page 129 and 130: Notice that we did not use the INNE
- Page 131 and 132: Note that I’m deliberately elimin
- Page 133 and 134: know thus far? Actually, the very l
- Page 135 and 136: Note that whether you use a LEFT or
- Page 137 and 138: Just two records are returned: Vend
- Page 139 and 140: The question you should be asking n
- Page 141 and 142: How It Works As you can see, we hav
- Page 143 and 144: An Alternative INNER JOIN Let’s d
- Page 145 and 146: Dave’s Data 1212 Smith Ave Dave
- Page 147 and 148: JOIN Sales.Customer sc ON pp.Busine
- Page 149 and 150: Now, look at the heart of what’s
- Page 151 and 152: 5 Creating and Altering Tables Ever
- Page 153 and 154: ackward compatibility to prior vers
- Page 155 and 156: Reviewing the Defaults So let’s l
- Page 157 and 158: NAME This one isn’t quite what it
- Page 159 and 160: deprecates the older sp_attach_db f
- Page 161 and 162: The second provides specifics about
- Page 163 and 164: ❑ When building tables based on o
- Page 165 and 166: The NOT FOR REPLICATION parameter d
- Page 167 and 168: Let’s look at the specific syntax
4<br />
JOINs<br />
Feel like a seasoned professional yet? Let me dash that feeling right away (just kidding)! While<br />
we now have the basic statements under our belt, they are only a small part of the bigger picture<br />
of the statements we will run. To put it simply, there is often not that much you can do with just<br />
one table — especially in a highly normalized database.<br />
A normalized database is one where the data has been broken out from larger tables into many<br />
smaller tables for the purpose of eliminating repeating data, saving space, improving performance,<br />
and increasing data integrity. It’s great stuff and vital to relational databases; however, it also<br />
means that you wind up getting your data from here, there, and everywhere.<br />
We will be looking into the concepts of normalization extensively in Chapter 8. For now, though,<br />
just keep in mind that the more normalized your database is, the more likely that you’re going to<br />
have to join multiple tables together in order to get all the data you want.<br />
In this chapter, I’m going to introduce you to the process of combining tables into one result set by<br />
using the various forms of the JOIN clause. These will include:<br />
❑ INNER JOIN<br />
❑ OUTER JOIN (both LEFT and RIGHT)<br />
❑ FULL JOIN<br />
❑ CROSS JOIN<br />
We’ll also learn that there is more than one syntax available to use for joins, and that one particular<br />
syntax is the right choice. In addition, we’ll take a look at the UNION operator, which allows us to<br />
combine the results of two queries into one.<br />
JOINs<br />
When we are operating in a normalized environment, we frequently run into situations in which<br />
not all of the information that we want is in one table. In other cases, all the information we want