SQL Saturday 117 Recap

The good thing about SQL Saturdays is that more often than not, you will eventually find one close to you - so for the third year in a row, I was glad to be an attendee at SQL Saturday Columbus - #117.  The event was held at Ohio Dominican University, which is just a short drive from my house. Since there's no travel / hotel stories this time, let's get right to the sessions!

So what I'm going to do this time is just list out the sessions I attended with a couple of my take-aways, as well as links to the speaker's website, twitter account, and presentation page on the SQL Saturday site, so you can download the slide decks, if they're available. (If not, check back later.) I'm doing things a bit different this time, since in all honesty, it's starting to seem kind of redundant to say, "so-and-so is an excellent speaker, the slides were entertaining, informative, they really knew what they were talking about, etc..."  Look over my previous recaps and you'll see what I mean. All of these speakers are excellent.  I've yet to attend a session that wasn't good. So if you're one of the 3 or so non-bots that are reading these recaps, and you've yet to attend one of these - GO. If nothing else, come and say hi to me and tell me how much better this blog could be if I would only [insert suggestion here...].

5 Database Design Blunders - Karen Lopez (www | twitter | presentation)

• Numbers are not just numbers, they have meaning, and sometimes you cannot treat numeric data as numeric data. 
• UUID - Usually Unique Identifier (Sounds about right. :-) )
• Have scripts for developing test data, deploying test data, and ensure access for devs to the data model.
• Defaults are not best practices. (10% database auto-growth, anyone?)
• IF you want a DB that follows best practices, you need a business that follows all best practices.

SQL Server and Sharepoint: Best Frenemies - Lisa Gardner (www | twitter | presentation)

• The Config and Admin databases must be backed up when SharePoint is stopped in order for the backup to be supported.
• Guidance states to try and keep the content databases under 200GB.  If you need more, create another content DB.
• Plan for about 2 IOPS per GB used.
• Auto-Create Stats should be off, and consider setting MAXDOP to 1. 

Women In Technology - Wendy Pastrick (www | twitter)

The irony of the "Sponsored by GoDaddy" icon on the slide wasn't lost on me.  I almost brought it up, but decided to let that one go for the time being. I had already stuck my neck out earlier in the session with a question that included the ever-popular "b-word". I tried to couch it in the most inoffensive way possible, which seemed to work, because it generated a lot of very good discussion. (Since it was an open discussion, there wasn't really a slide deck to speak of, so no presentation link.)

One other point that was raised that I wanted to comment on, but ran out of time was: When creating a team, do you include diversity for the sake of diversity, or do you just pick the best from the available candidates, regardless of their makeup? In other words, would you hire a woman who was slightly (slightly) less qualified than a man, simply because she's a woman? I think it depends on whether or not you see diversity as an advantage in and of itself.  I'm still doing a lot of thinking about this one, but I'm starting to lean towards "yes". In any team, you will have more qualified people, and less qualified people. You can teach people technology. You can't teach people to be diverse. You have to put the diversity there, and though I am sure such situations may exist, I have never seen a situation where a diverse team was at a disadvantage because of their diversity. It has almost universally been an advantage. So yes, I would specifically want to add different genders, races, levels of experience, etc...

Also, I mentioned that there was a study done recently that showed that the more diverse a team is, the higher the average intelligence is. Here's a link to the abstract for that study: Evidence for a Collective Intelligence Factor in the Performance of Human Groups. (Apologies for the mandatory registration, if you want to read the full text, but I wanted to link to the actual study, not a news report on it.)

Parallel Execution Plan Deep Dive - Kevin Boles (twitter | presentation)

This session may have been juuuuuust a touch over my head, but I was glad I attended anyway. I have a lot to research now.

• Parallelism is designed to improve response time for big queries, but can reduce throughput, and add overhead to execution.
• Designed for OLAP, not OLTP. In fact, some OLTP applications benefit from turning parallelism off. (TEST! ymmv...)
• Linear scalability means twice the CPU with the same workload = half the response time.
• Prallelism means horizontally partitioning input data, and bucketizing the data stream into one or more sets of data.
• Requirements for parallel execution:
• More than one CPU (core) to work with.
• MAXDOP set to more than 1 (avoid 0).
• Cost Threshold for Parallelism must be less than Query Cost (default is 5).
• Max Worker Threads must be great enough to actually run the query.

Execution Plan Deep Dive - Grant Fritchey (www | twitter | presentation)

• When reading execution plans, Left to Right is the logical order, Right to Left is the physical order of operations.
• ANSI Settings are stored in the plan. 
• When examining a Clustered Index scan, be sure to note the scan direction. 

Powershell for DBAs - Kevin Bullen (www | twitter | presentation)

• Powershell was meant to replace cmd.exe, but became scripting language instead.
• Meant for tasks that benefit from script re-use.
• The help commands and aliases are your friends. Know them, love them.

And then...

Dinner at the Old Bag of Nails in Gahanna was excellent as usual. The fried pickles and fish n' chips are their signature dishes, and deservedly so. There was much geekiness around the table, as conversation drifted between the local Origins game convention, sci-fi shows we liked, and occasionally, SQL Server. Then it was off to karaoke at Scotch and Soda, a local watering hole that made up for it's slightly smaller list of available beers with a large number of awesome singers. Seriously, this was one of the best crowds of singers I've heard at karaoke in a long time. We had a fantastic R&B stylist, some great Country ladies, and of course, the SQL Karaoke crew. The singing went long into the night, and once again, I didn't get home until about 2:30-ish.

Once again, thank you to all the organizers, speakers, and volunteers for putting on a great event. The next one I'm planning on is SQL Saturday #126 in Indiannapolis on July 28th.  I hope to see you there.

Thanks,
-David.