PASS 2008: Days 2 & 3

Thursday and Friday of the PASS Community Summit blurred together a bit for me.  Not because of the parties Thursday night which apparently left many people bleary-eyed, but the cold medicine I was taking sure didn't help things.  But primarily because I bounced in and out of a few sessions and had some work stuff mixed in.  And on top of that, my 5-month old waking up every couple of hours throughout the night did not make for very restful nights.  Oh well, the things I endure for personal development.  ;-)

Here are a few of the miscellaneous lessons I learned or was reminded of:

  • When attending a conference, be sure to read the detailed description in the program guide of the sessions you are planning to attend.  There were a couple of times where I went to a session based primarily on the Title of the session, only to find out that I had misinterpreted it, and the session was not at all about the topic I was expecting.  Unfortunately, by the time I figured it out, it was a toss-up whether I could get into another session that interested me.  There were several sessions that were Standing Room Only, so if you weren't there at the beginning of the session, you might be out of luck.
  • XML is not necessarily evil.  OK, I didn't really think it was evil, but I have been very skeptical of its value in the database.  I am not one to abandon my Relational designs and thought patterns on a whim.  But Denise gave a great presentation on her experience implementing XML for a large project, and I completely understand and agree with her reasoning for doing so.  There were specific conditions in her project which made using XML palatable, and even attractive.  In particular, she had collections of element and attribute data that was hierarchical, had to be portable, and the required structure would change (in fact she already had multiple "schemas" she needed to represent for different records).  And best of all, in this particular system, the data that was being stored in XML would not be queried in segments.  Primarily she would want all of the XML returned based on other data elements in the record.  Sounds perfect to me.
  • In SQL 2005, the Execution Plan when shown in XML will display information on indexes that SQL Server thinks would have been helpful, but are missing.  In SQL 2008, this information is also visible in the graphical execution plan.
  • If your Stored Procedure is only going to return one row (e.g. GetRecordByPK) then you should consider using Output Parameters instead.  There is some overhead to producing a recordset and sending it down the line; and a handful of Output Parameters may be a lot more efficient.
  • Beware of Implicit Data Conversions in your JOINS and WHERE clauses (e.g. comparing a VARCHAR column to an NVARCHAR variable or a DATETIME column to a string literal date).  In SQL 2008, the impact of this was greatly lessened, but in SQL 2005 and earlier, the impact is similar to placing a function in the statement which is to say that it can seriously hurt performance.
  • Remember in SQL 2005 that you can build covering indexes by "INCLUDE"ing columns in the index that are not actually key parts of the index.  For example, you may build and index on LastName, FirstName and INCLUDE MiddleName so that whenever you need to search and display the full name, you don't have to do a Key Lookup to get the middle name, but you also will not have so many splits occurring because your index is keyed on just LastName, FirstName.
  • The new DATETIMEOFFSET data type in SQL 2008, while being Time Zone aware, it is NOT intrinsically aware of Daylight Savings Time.
  • Microsoft is considering a FOREACH construct in T-SQL for some future release of SQL Server.  On the one hand, I like how much simpler it is to understand than the current CURSOR constructs.  On the other hand, given the frequency with which they perform poorly, I don't really want to make creating cursors any easier for developers, lest we encourage them to do it more often.
  • ENUM is another feature under consideration for some future release of SQL Server (T-SQL).  This one I like.  I can definitely see a few places where I would like to use an ENUM in some procedure code.

There was so much more to the conference than this, but here are few things to whet your appetite and help you see the benefit of attending next year.  Remember that on top of this, there was a huge track on BI stuff, several presentations by Microsoft folks, and easy access to the SQL CAT group.

I hope to see you all there next year!

PASS GO 500

And you thought that you only got $200 for passing GO, didn't you?  Well, this isn't Monopoly, my friends, this is SQL Server.  And while attending the PASS Community Summit this year, I saw Joe Webb do this trick.  I wasn't the only one in the crowd who went, "Wha???" when they saw it.

Most of you readers already know that GO is not a SQL command, but rather it is the commonly used word to separate batches.  In other words, the client tool (Query Analyzer, SQL Management Studio, OSQL.exe, etc.) parse whatever commands you execute, separating them into batches whenever GO is found.  (Actually, GO is not a magic word by itself, you can set the "batch separator word" to be whatever you want in the Options panel of Query Analyzer and Management Studio.)

Well, it turns out that in SQL 2005, a new option was implemented whereby you can put a number after the GO command and that will cause the batch to be executed that many times.  This does not work in SQL 2000 and earlier.  Here's an example if you want to test it out for yourself.

-- Create a test table to use in our test. CREATE TABLE dbo.TestGo (
RecID INT NOT NULL IDENTITY(1,1),
SomeText VARCHAR(50) NULL
) GO

-- Now a simple test to prove that this next batch is being executed multiple times.
INSERT INTO dbo.TestGo VALUES ('This is a test.') 
GO 500

-- Look at the records to prove it worked
SELECT * 
FROM dbo.TestGo
-- Now let's cleanup after ourselves.
DROP TABLE dbo.TestGo 
GO

So there you have it.  The batch that precedes the GO with a number is executed however many times you specify.  I cannot say at this point that I would recommend using that for anything other than ad-hoc testing, perhaps to simulate a load; or possibly to generate some quick test data.  But I thought it was a neat trick and after proving to myself that it really worked, thought I would share it.  And for those who are curious, yes, this is documented in Books On-Line.

UPDATED: Added formatting to code blocks.

«November»
SunMonTueWedThuFriSat
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456