Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

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.

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!