Ajarn Mark Caldwell Blog

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!