SQL Tact

pointers, solutions and scripts for the SQL DBA
not intended to replace common sense


Presentation Downloads from SQL Saturday Columbus GA 2015

Thanks for joining us at SQL Saturday Columbus today on a gorgeous day to go inside and learn about SQL Server! And even bigger congrats to those of you who use Google maps and were still able to find the brand new event location at the Troy State University Riverfront campus!

My colleagues Cody Gros and John Walker joined me on a trek from Louisiana earlier this week and I was so happy to see my SQLSaturday friends, including the great and magnificent SQL Saturday empress Karla Landrum, once again.

A special thanks and job well done to Tim Radney for organizing this top notch event throughout a rough week and the loss of his father. Friends are all over the place Tim, glad so many of us could be here today to tell you this in person instead of from afar. Great job, great facility, great event, great people.

Here are the downloads for two presentations. These presentation files are also available on the SQLSaturday event website.

SQL + SharePoint: Friends Forever (William Assaf and Cody Gros)
12:30pm in room 213

SQL Admin Best Practices with DMVs
3pm in room 310

Downloads here:

Sorry, no, we won't be uploading our Sparkhound Jeopardy game from the lunch session. Can't be giving away all our answers! Er, questions.


Why I Don't Use the Architect Title

I get nervous when I see the title "architect" in IT job roles.

I've had this title before as an employer's standard, but lobbied against it. I instead prefer separating job titles from project roles.


"Architect" as an IT role descriptor carries an appropriate level of technical expertise and broad experience - but typically, for too long. I don't like "Architect" because it sticks.

The verb "architect" implies a leadership and guidance in big system design decisions.
The noun "architect" can be a bludgeon in a software planning meeting.

Putting egos aside when making platform and architecture decisions can be next to impossible if someone decides to wield the "architect" hammer.

Can you think of a situation when large amounts of dated technical experience did not make for quality technical guidance in the future? I bet you can. I bet you know exactly the type I'm talking about.

Platforms, language versions, feature sets and even product suites change regularly, so a clingy title like "architect" may be appropriate for only one or two projects or generations of a given technology. A few major releases, framework versions or platform changes later, and the "architect" title may be as stale and waning as the technical skillset behind it. Without continuing education, "architect" becomes synonymous with "boat anchor".

When the next project comes, the "architect" resource from the original project may be (not as a rule) more gentrified than skilled. And while the "architect" doesn't need to be the most technically savvy member of a project team, the assumption that "architect" was an applicable title a few years ago - and so shall ever be - is a dangerous trap.
  • The "architect" for your SQL 2005 project needs to get up to speed on the latest changes (ex: data types, high availability, and columnstore indexes) before serving in a similar role for your new SQL Server 2014 project.
  • The "architect" for your .NET v2.0 project that's now in maintenance would perhaps better serve as a developer for your new .NET 4.5 project. 
  • The "architect" for your first-iteration Entity Framework 4 project might not be ready to carry the lead that new EF6 application.
  • The "architect" for your SQL Server 2008 R2 SSAS multidimensional business intelligence platform may not be aware of architecture features involved in your new SharePoint-based business intelligence project leveraging SSAS Tabular and PowerBI.
Instead of your top-tier developers assuming the title of "architect", try using the names with transient intent, like Project Lead, Team Lead, Technical Lead, Designer, Analyst or Developer.

In summary, please make sure that you and your coworkers aren't treating "architect" like academia treats tenure. It's not a lifetime appointment, and the ego boost that comes with "architect" needs to give way to honesty, humility and continuing education.


I Was Once a Very Crappy Carpenter + SQL Bolts to Buzzwords

Tonight I spoke to Dr. Alkadi's CMPS 411 class, which was hijacked by the Hammond .NET User Group onsite at Southeastern University! Thanks once again to Sparkhound who sponsored!

Here's the slide deck for my presentation, which combined two topics I wanted to talk about. The first, I Was Once a Very Crappy Carpenter, is about my personal journey early in my career from unmotivated "carpenter" to motivated "carpenter," which I think is relevant for folks in the IT industry at any experience level. The second, SQL Bolts to Buzzwords, is a ground-floor introduction to SQL Server database technology and core concepts about ACID fundamentals, data types, and disaster recovery that are crucial for developers/students to grasp.

Remember, stay away from floats and guids, stay in school, and eat your vegetables (pizza counts).

Thanks for attending, hope you enjoyed the presentation!