Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Chapter 7: Adding More to Our Queries These are just the highlights. The possibilities of different mixes and additional situations are positively endless. I can’t stress enough how important it is when in doubt — heck, even when you’re not in doubt but performance is everything — to make reasonable tests of competing solutions to a problem. Most of the time the blanket rules will be fine, but not always. By performing reasonable tests, you can be certain you’ve made the right choice. Summary The query options you learned back in Chapters 3 and 4 cover perhaps 80 percent or more of the query situations that you run into, but it’s that other 20 percent that can kill you. Sometimes the issue is whether you can even find a query that will give you the answers you need. Sometimes it’s that you have a particular query or sproc that has unacceptable performance. Whatever the case, you’ll run across plenty of situations where simple queries and joins just won’t fit the bill. You need something more and, hopefully, the options covered in this chapter have given you a little extra ammunition to deal with those tough situations. Exercises 1. Write a query that returns the hire dates of all AdventureWorks2008 employees in MM/DD/YY format. 2. Write separate queries using a JOIN, a subquery, and then an EXISTS, to list all Adventure- Works2008 persons who have not placed an order. 3. Show the most recent 5 orders that were purchased from account numbers that have spent more than $70,000 with AdventureWorks. 214
8 Being Normal: Normalization and Other Basic Design Issues I can imagine you as being somewhat perplexed about the how and why of some of the tables we’ve constructed thus far. With the exception of a chapter or two, this book has tended to have an online transaction-processing, or OLTP, flair to the examples. Don’t get me wrong; I will point out, from time to time, some of the differences between OLTP and its more analysis-oriented cousin Online Analytical Processing (OLAP). My point is that you will, in most of the examples, be seeing a table design that is optimized for the most common kind of database — OLTP. As such, the table examples will typically have a database layout that is, for the most part, normalized to what is called the third normal form. So what is “normal form”? We’ll be taking a very solid look at that in this chapter, but, for the moment, let’s just say that it means your data has been broken out into a logical, non-repetitive format that can easily be reassembled into the whole. In addition to normalization (which is the process of putting your database into normal form), we’ll also be examining the characteristics of OLTP and OLAP databases. And, as if we didn’t have enough between those two topics, we’ll also be looking at many examples of how the constraints we’ve already seen are implemented in the overall solution. This is probably going to be one of the toughest chapters in the book to grasp because of a paradox in what to learn first. Some of the concepts used in this chapter refer to things we’ll be covering later — such as triggers and stored procedures. On the other hand, it is difficult to relate those topics without understanding their role in database design. I strongly recommend reading this chapter through, and then coming back to it again after you’ve read several of the subsequent chapters.
- Page 202 and 203: Chapter 6: Constraints Cascading Ac
- Page 204 and 205: Chapter 6: Constraints 166 This is
- Page 206 and 207: Chapter 6: Constraints 168 FROM Ord
- Page 208 and 209: Chapter 6: Constraints 170 Let’s
- Page 210 and 211: Chapter 6: Constraints CHECK Constr
- Page 212 and 213: Chapter 6: Constraints Defining a D
- Page 214 and 215: Chapter 6: Constraints Ignoring Bad
- Page 216 and 217: Chapter 6: Constraints Try running
- Page 218 and 219: Chapter 6: Constraints Rules and De
- Page 220 and 221: Chapter 6: Constraints Dropping Rul
- Page 222 and 223: Chapter 6: Constraints 184 Restrict
- Page 225 and 226: 7 Adding More to Our Queries When I
- Page 227 and 228: Building a Nested Subquery A nested
- Page 229 and 230: While this works just fine, queries
- Page 231 and 232: We’ll go back to the AdventureWor
- Page 233 and 234: ❑ Aliases are used in both querie
- Page 235 and 236: Now let’s see this at work in our
- Page 237 and 238: So let’s take this now and apply
- Page 239 and 240: This join-based syntax, for example
- Page 241 and 242: IF NOT EXISTS (SELECT ‘True’ FR
- Page 243 and 244: The conversions can actually get a
- Page 245 and 246: there are no other roll up records
- Page 247 and 248: GROUP BY soh.OrderDate, sod.Product
- Page 249 and 250: OUTPUT $action, inserted.Year, inse
- Page 251: The long-standing, traditional view
- Page 255 and 256: Chapter 8: Being Normal: Normalizat
- Page 257 and 258: Chapter 8: Being Normal: Normalizat
- Page 259 and 260: Chapter 8: Being Normal: Normalizat
- Page 261 and 262: Chapter 8: Being Normal: Normalizat
- Page 263 and 264: Chapter 8: Being Normal: Normalizat
- Page 265 and 266: Chapter 8: Being Normal: Normalizat
- Page 267 and 268: Chapter 8: Being Normal: Normalizat
- Page 269 and 270: Chapter 8: Being Normal: Normalizat
- Page 271 and 272: Chapter 8: Being Normal: Normalizat
- Page 273 and 274: Chapter 8: Being Normal: Normalizat
- Page 275 and 276: Chapter 8: Being Normal: Normalizat
- Page 277 and 278: Chapter 8: Being Normal: Normalizat
- Page 279 and 280: Chapter 8: Being Normal: Normalizat
- Page 281 and 282: Chapter 8: Being Normal: Normalizat
- Page 283 and 284: Chapter 8: Being Normal: Normalizat
- Page 285 and 286: Chapter 8: Being Normal: Normalizat
- Page 287 and 288: Chapter 8: Being Normal: Normalizat
- Page 289 and 290: Chapter 8: Being Normal: Normalizat
- Page 291 and 292: Chapter 8: Being Normal: Normalizat
- Page 293 and 294: Chapter 8: Being Normal: Normalizat
- Page 295 and 296: Chapter 8: Being Normal: Normalizat
- Page 297 and 298: Chapter 8: Being Normal: Normalizat
- Page 299 and 300: 9 SQL Ser ver Storage and Index Str
- Page 301 and 302: Page Splits When a page becomes ful
Chapter 7: Adding More to Our Queries<br />
These are just the highlights. The possibilities of different mixes and additional situations are positively<br />
endless.<br />
I can’t stress enough how important it is when in doubt — heck, even when you’re not<br />
in doubt but performance is everything — to make reasonable tests of competing solutions<br />
to a problem. Most of the time the blanket rules will be fine, but not always. By<br />
performing reasonable tests, you can be certain you’ve made the right choice.<br />
Summary<br />
The query options you learned back in Chapters 3 and 4 cover perhaps 80 percent or more of the query<br />
situations that you run into, but it’s that other 20 percent that can kill you. Sometimes the issue is whether<br />
you can even find a query that will give you the answers you need. Sometimes it’s that you have a particular<br />
query or sproc that has unacceptable performance. Whatever the case, you’ll run across plenty of<br />
situations where simple queries and joins just won’t fit the bill. You need something more and, hopefully,<br />
the options covered in this chapter have given you a little extra ammunition to deal with those tough<br />
situations.<br />
Exercises<br />
1. Write a query that returns the hire dates of all AdventureWorks<strong>2008</strong> employees in MM/DD/YY<br />
format.<br />
2. Write separate queries using a JOIN, a subquery, and then an EXISTS, to list all Adventure-<br />
Works<strong>2008</strong> persons who have not placed an order.<br />
3. Show the most recent 5 orders that were purchased from account numbers that have spent more<br />
than $70,000 with AdventureWorks.<br />
214