Do Not Be Afraid To Learn

I had been wrestling with what to write about this week. I'll be up front and honest (and may have even said this in an early post), I am not going to be breaking new technical ground in this blog. I consider myself to be intelligent enough to do good work and I can explain myself well to sufficiently make a case for or against doing something either in the gym or the database space. However, I am not necessarily writing to demonstrate some sort of new technique or function that's bleeding edge. My hope is that you find something interesting, entertaining, and educational enough that enables you to take a step back an revisit basics that help you get over a particularly troublesome query or break past a Personal Record (PR) in the gym.

With that in mind, I blindly stumbled into today's topic: Don't Be Afraid to Learn. I would venture to say that most of us are not averse to learning. In my line of work if you're not attempting to learn something new every day, you will get passed by. Be it for a promotion or that new up and coming junior DBA. Nay, it's more to say, don't believe yourself so highly that you cannot be taught.  I have two examples to share; one from the gym and one that just occurred today in my work.

In the Gym

Last week, I took a video from a side angle of my squat for the day. The goal was 8-10 reps for the set. In my brain when I'm doing squats I feel like I am super deep, that my knees can bend no further. I watch the video back and discover I am barely breaking parallel. Pic included

I watched the video and became frustrated with myself. It felt so good! I was so low, how am I still so high? Discouraged with this first set, the rest in this workout steadily got worse. Alas, I digress.

I posted the video and asked for feedback. Now, full disclosure, a part of me....a portion, a smidge, a miniscule amount....of me was seeking validation. "No, no man, that's really good!"  "You're fine, just do what you can." However I truly did want to know what I could do to fix this.

I have had a few folks reach out, one of which is the trainer for my wife and I. She immediately diagnosed my issue of ankle mobility. My ankles are stiff and not allowing me to reach much deeper. I need to do mobility work on them, stretch them out just like I do my hips and legs before a tough leg day. 
Another trainer reiterated the same sentiment, the ankles. Now she also indicated that were I in a competition, this passes depth requirements. That made me feel decent. Not that I am about to go compete now. Those men and women are just built different!

The point of this particular example, I have been squatting for about 4 years now. I thought I knew the form, the technique. For the last few months I've been frustrated knowing I should be able to get deeper in the movement, yet still seemed stuck. I finally break down and ask for guidance. Wouldn't you know, turns out there are people more educated than me on the subject and instructed me. Kooky.

In the Workplace

This one is incredibly tough to admit. I don't know TSQL as well as I think. Gasp, shock, horror! I know, I was stunned too. I've been doing this for over 20 years now, surely I can't learn anything new. Oh arrogant and prideful Viking DBA. 

Here's what I encountered today. I had a query that was running longer than I'd like. I'm analyzing the query plan, looking for potentially obvious issues. When I notice a piece of syntax I have not used nor seen very often before; OUTER APPLY. What on earth is OUTER APPLY? I imagine if some seasoned DBAs are reading this they're screaming at me. "How can you not know that? It's basic TSQL functionality." That is perhaps true, nevertheless it's new to me.

So what does this do? Well, it's similar to a regular OUTER JOIN, but allows you to join a left side table to a right side inline mechanism such as a Table Valued Function or correlated subquery.
An example might be: 

    SELECT c.CustomerID, c.CustomerName, o.OrderID, 0.TotalAmount 

    FROM Customers c 

    OUTER APPLY GetLatestOrdersByCustomer(c.CustomerID) AS o

I'm sending the CustomerID to a Table Valued Function that will return the most current order information for each customer.

You could also do this same Example as:

    SELECT c.CustomerID, c.CustomerName, LatestOrder.OrderNumber, LatestOrder.OrderDate

    FROM Customers c

    OUTER APPLY (

            SELECT TOP 1 OrderNumber, OrderDate

            FROM Orders o

            WHERE o.CustomerName = c.CustomerName

            ORDER BY o.OrderDate DESC

            ) as LatestOrder

No real preference as to which one to use, try them both out and see what's more effecient.

Here is how my thought process went. 

"Ok, I get that. But it's kind of the same thing I'm doing when I use a ROW_NUMBER() function in a CTE and then I join my CTE where RowNum = 1 (or whatever). How is this different." 

Example of what I would use in this scenario:

WITH LatestOrder AS (

    SELECT CustomerName, OrderNumber, OrderDate, 

    ROW_NUMBER() OVER (PARTITION BY CustomerName ORDER BY OrderDate Desc) AS RowNum

    FROM Orders

    )

SELECT c.CustomerID, c.CustomerName, LatestOrder.OrderNumber, LatestOrder.OrderDate

FROM Customers c

LEFT JOIN LatestOrder on LatestOrder.CustomerName = c.CustomerName

    AND RowNum = 1

Oh sweet arrogance. At this point, I swallowed my pride and opened CoPilot. Now, next week's topic is going to be on how I'm beginning to use AI. And you'll read how I am not ncecessarily fearful of it, but how I value it. I'll dive more into that next week. But for today, I asked it in pretty plain English what makes OUTER APPLY different from how I've been doing my CTE for the last 15 years.

Using OUTER APPLY you're only having to get 1 record back for each row in your left table. Whereas with my CTE option, it has to read the full dataset and store in memory. Oh my goodness, yes! You're one hundred percent correct! Nine times out of 10 when I'm using the ROW_NUMBER function, I only want the top option anyway, why am I querying the whole result set and joining to that? Such a waste of memory and processor time! From this point forward, I'll be rethinking how I complete operations when something like this is required.

One caveat to the above, overall performance will still be dictated by how good your indexes are. I ran both queries on some junk tables I created for this exercise that had no indexes yet. They both performed about the same with the latter actually eeking out the former. However, soon as I added an index on the orders table with the relevant fields, it smoked the second one. Indexes matter kids!

The Takeaway

It is very easy to become complacent in our jobs, working out, heck even life in general. We oftentimes think we have it all figured out and are unable to accept that maybe there's a better way of completing a task (or a script). Certainly I cannot speak for all us, but I've had that revelation twice this week. All I'm saying is be open to the notion that maybe you don't know it all. That someone with experience has encountered what you face before and can help you overcome the hurdle in front of you. Do not be afraid to admit you don't know what you don't know.