T-SQL Tuesday #128: Learn From Others - July 2020

I don't write enough here. I let myself get too busy, and I often miss things that I want to write about. I have several articles that I've started and dropped and several ideas that I never even started. I do a great job of lurking and not a good enough job of participating when I should. So it's no surprise to me that I've been sitting on this post for a week and missed the deadline to officially participate. 

T-SQL Tuesday #128 for July 2020 was hosted by a friend of mine; someone I worked with a few years; and the person who is directly responsible for my transition from just a ColdFusion Programmer to also a SQL Developer (and now a DBA). 

When @AirborneGeek came to work with me, I was primarily a programmer who knew just enough SQL to literally be dangerous. I could get a query to return the data I wanted, no problems there. I had fallen into the normal trap of "My queries are slow. It's gotta be the database's fault." Or Network. But we all know the network is the cause of 99.9% of all problems, right? 

I think one of the primary reasons we even created his team was because we were an application running off of millions of records, with NO database experts, and our applications were slow. 

Specifically the reason why I became somewhat fascinated with SQL was because I ended up being responsible for an internal report that had to be run overnight because it ran for HOURS. I can't remember if I was the original author of said report or not (wouldn't be surprised), but it didn't really matter since it was my responsibility now. I thought it could do better, so I approached our new database team to see if they were smarter than me. Everyone knows that programmers are smarter than DBAs anyway, but I figured "What the heck?". I gave him my query. 

He held onto it for a couple of days, and when he handed it back to me, it looked nothing like what I had given him. But it gave me the same data and ran in only a few minutes! 

It may have been Voodoo, or it may have been Black Magic. Regardless, if not for my silly internal fault of always wanting to know "Why?", I'd be on a MUCH different career path.

Over the next couple of years, I had plenty of questions for him and the rest of the Database Team. The more I learned about how the database was supposed to work, the more I came to realize how wrong I had been doing things. That team taught me about how to do proper JOINing, proper indexing and generally how to make things faster and much more efficient. Also about how important it was to not accidentally write a Cartesian JOIN on a 10M row table.  ( Just FYI: That can apparently discover the memory limits of your SQL Server and earn you a desk visit from the DBA.) 

I know that my questions for @AirborneGeek probably seemed very basic to him. He always showed me patience when he answered my questions. He never treated me like an ignorant programmer, though in hindsight, I realize now how basic some of my questions must have seemed. So, What Can I Learn From Others?

As another pilot, I completely agree with the premise that piloting and DBAing have a LOT of similarities (disasters differ in magnitude, but are very similar in remediation, and a lot can be learned from other people's "Uh-oh" moments). 

My post really isn't so much about how I've learned to deal with SQL disasters, but about how I've learned to be grateful for the people who got me here. 

I can't say it enough, "Thank you, Kerry."

Though I guess I should also point out that the curiosity that was sparked has also led me to learn more about certain types of disaster remediation and recovery than I ever really wanted to know. So "Thanks again, Kerry."