17.06.2013 Views

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

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

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 7: Adding More to Our Queries<br />

deleted.Year,<br />

deleted.Month,<br />

deleted.ProductID,<br />

deleted.QtySold;<br />

This time we see more than one action and, in the case of UPDATED results, we have data for both the<br />

inserted (the new values) and deleted (the old values) tables:<br />

$action Year Month ProductID QtySold Year Month ProductID QtySold<br />

---------- ------ ----- ----------- ----------- ------ ----- ----------- ----------<br />

INSERT 2003 8 928 2 NULL NULL NULL NULL<br />

INSERT 2003 8 882 1 NULL NULL NULL NULL<br />

UPDATE 2003 8 707 249 2003 8 707 242<br />

…<br />

…<br />

UPDATE 2003 8 963 32 2003 8 963 31<br />

UPDATE 2003 8 970 54 2003 8 970 53<br />

UPDATE 2003 8 998 139 2003 8 998 138<br />

(38 row(s) affected)<br />

Performance Considerations<br />

We’ve already touched on some of the macro-level “what’s the best thing to do” stuff as we’ve gone<br />

through the chapter, but, like most things in life, it’s not as easy as all that. What I want to do here is provide<br />

something of a quick reference for performance issues for your queries. I’ll try to steer you toward<br />

the right kind of query for the right kind of situation.<br />

Yes, it’s time again folks for one of my now famous soapbox diatribes. At issue this<br />

time is the concept of blanket use of blanket rules.<br />

What we’re going to be talking about in this section is the way that things usually<br />

work. The word “usually” is extremely operative here. There are very few rules in<br />

<strong>SQL</strong> that will be true 100 percent of the time. In a world full of exceptions, <strong>SQL</strong> has<br />

to be at the pinnacle of that — exceptions are a dime a dozen when you try to describe<br />

the performance world in <strong>SQL</strong> <strong>Server</strong>.<br />

In short, you need to gauge just how important the performance of a given query is.<br />

If performance is critical, then don’t take these rules too seriously — instead, use<br />

them as a starting point, and then TEST, TEST, TEST!!!<br />

JOINs versus Subqueries versus ?<br />

212<br />

This is that area I mentioned earlier in the chapter that I had a heated debate with a coworker over. And,<br />

as you might expect when two people have such conviction in their points of view, both of us were correct<br />

up to a point (and, it follows, wrong up to a point).

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

Saved successfully!

Ooh no, something went wrong!