Voice of the DBA

Author: way0utwest

  • The Fringe Festival

    I was lucky enough to take a vacation a decade ago in Edinburgh with my wife. She came over to the UK with me for a quick trip. We had never been to Scotland together, so we trained up and stayed in Stirling. We walked around the area, visited the Wallace Monument and toured Edinburgh.  We hiked up Arthur’s Seat and piled stones on a sunny August afternoon.

    2026-07_0161

    We hadn’t planned it, but the Edinburgh Fringe Festival was going on at the time. We saw lots of street performers and wandered into a few comedy and music shows in random places. It was a fun time and we’ve always wanted to go back.

    We’re back this year. We trained up earlier today and are spending a few days here, taking in a few shows and unwinding from life. My wife has had a busy year with work and we’ve been aiming to get away every month and recharge a bit. This is our August trip after a few days in Napa in July.

    In the spirit of Amy Abel learning to recharge and detoxing, we’re getting away. I don’t know that we’ve avoiding technology, but we are avoiding the work things that create stress and take away from life.

    Make sure you take your vacation and get breaks away from the things that stress you out.

  • Building Great Software

    Most of us will work on software for our organization, and we might not want to or care about the end result being great. We do want it to work, and we want clients to find it useful. If we have external customers using our systems, maybe we want it to be great. In most of my experience, people are often proud of their work, sometimes ashamed, but not many people spend a lot of time making their corporate applications great.

    Often because we don’t have (or aren’t allowed) the time to do so.

    Basecamp is a popular SaaS project management solution, and Hey is a reimagined email service that many people love. One of the founders of the company wrote an interesting post on software being built that starts with this sentence: “The speed at which a product is developed doesn’t inherently make the product better or worse.”

    It’s a bit of a shot at AI, but it also goes into the fact that we often measure our software process in ways that aren’t about the output. Most organizations have abandoned lines of code as a metric, but I do see commits or PRs being used, as well as other metrics. Trying to decide if your developers are effective isn’t a horrible idea; after all, we should be ensuring that they are getting something done, but none of those metrics necessarily help us make better software.

    I see that at Redgate, as we incorporate AI into our work. A lot of the things that make software take time aren’t solved with AI. They’re solved with deep understanding of the problem space, what your customers need, and what helps them work well. AI accelerates some things, but we still need product people empathizing deeply with customers and designers watching for UX issues that create friction for customers. AI can help speed up the experiments and outputs in some ways, but just adding in chatbots or AI agents that write code isn’t necessarily useful.

    There are a lot of decisions in building software. What to do, what not to do, what’s more important than something else, and of course, what approach to take in the architecture. That’s before we even get to performance, which is something that far too often gets ignored, at least for the code being run against databases. Building great software is hard, but it can be done, and AI can help.

    You just need talented humans guiding the process.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Why Use TRY_PARSE(): #SQLNewBlogger

    Someone asked why I would use TRY_PARSE after I posted a question at SQL Server Central: Getting the Average. Isn’t is slower?

    A fair question. This quick post looks at why.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    A Quick Setup

    The question above has the setup code, but what if I add another row? For example, I’ll run this .

    insert dbo.commission
    (
        salesperson
      , commission
    )
    values
    (‘Steve’, ‘A’)

    Now, let’s look at the data and run the query from the question.

    2026-07_0371

    This works. However, let’s remove the (slow) TRY_PARSE() from the aggregate.

    2026-07_0372

    Error. Why? I can’t convert “A” in the AVG to a number. It fails.

    You might think, I’ll never get bad data like this. But you might? A user might enter something you don’t expect. An AI might model this as a string, which is bad, but it happens. If it’s an EAV type table, or there are other data  items and you’re trying to extract the numbers from here, TRY_PARSE is helpful.

    SQLNewBlogger

    I wrote a post last week and this is a followup that really just took less than 5 minutes to setup and run. Plus I responded for the user in the post.

    This showcases me thinking about a question and situation and really gives an interviewer something to ask me. This lets them dive into my thought process and gives them confidence I don’t just write code without thinking.

    Add to your blog with short posts like this (or drop on LinkedIn).

  • T-SQL Tuesday #201: Temp Tables

    This month we have a new host, which I am grateful for. So many people have stopped blogging that it’s a challenge to keep this going. Jeff Taylor has an invite asking us about a core T-SQL topic that can affect the performance of your app and your server: temp tables.

    This is an interesting one for me, as I’ve changed my mind on these over the years, especially as Microsoft has made improvements to the SQL Server storage engine and query processor that have helped tempdb to perform better.

    They’ve also added things that can impact and load tempdb.

    If you want to host a T-SQL Tuesday, ping me. I’m always looking for new (or returning) hosts.

    My Answer

    My answer to Jeff’s question of temp tables as friend or foe is yes.

    They are friends.

    They are foes.

    Most things that we struggle with in database work are tradeoffs. We have to balance the demands. It’s why we say “it depends” so often because we have to find a way to do more of one thing, while accepting less of another.

    If I use temp tables in a query, I can potentially run a query to get a smaller data set that I can query with to get the results I need. I can reduce the memory grant, which might be required if the initial query scans a lot of data.

    Suppose I have a 100mm row table. If I am doing a complex join of this data on unindexed columns with multiple other tables, perhaps I want to do something like this (delivereddate might not be indexed):

    select c.customerid, o.orderid, o.delivereddate, oho.shipperid, o.salespersonid, ,qty, oh.price
into #limitedorders
from orderheader oh inner join orderdetail od on oh.orderid = oh.orderid
where customerid = 12

    This can get me a filtered list of things, which I can then join this temp table with the customer, shipper, salesperson, and other tables, which will be a smaller, quicker join.

    However, a temp table can be a problem as well. If you have a query that does something like this:

    select *
into #orderlist
from orderheader oh inner join orderdetails od
on oh.orderid  = od.orderid
where oh.orderdate > dateadd(year, –10, getdate()

    And then you have some sort of query that aggregates across the years.

    select c.customername, sum(t.qty * t.price)
from #orderlist t
inner join customer c
on t.customerid = c.customerid
where customerid = 12

    I’ve done a lot of work in the first query to gather data, allocate space in tempdb, copy this over, use memory, etc. Then I am going a simple query to aggregate things, and filtering it. In this case, the developer likely followed a pattern of gather data, then sum it from other queries. It might have worked for them, but if I have 1mm orders a year, this will suck up resources.

    My Advice

    My advice is like Jeff’s. In general, try to work with a query to solve your problem. Use joins, beware of views, and make sure you’ve indexed well. Use CTEs to break down your problem, and don’t use temp tables.

    If you struggle to get a single query, or you have poor performance because of memory grants or other issues, then think about shrinking your dataset down using a temp table and indexed columns. Then join this to get other data that you need.