Voice of the DBA

Category: Editorial

  • Development Is Fun

    I was listening to The Pragmatic Engineer interview Casey Muratori about high-performance code, which I found really interesting. I’m actually considering going through his Performance Aware Programming series and (re)learning some assembly. I never thought I’d even consider doing that. I learned Assembly in high school and university, and I didn’t enjoy it.

    Casey is a game programmer, and there was a question in the interview about how he uses AI tools in his work. “We are not using them” was not the answer I expected. Perhaps even more interesting was the rest of the answer. Casey loves programming and wants to enjoy what he does. He writes the code because he wants to do the work. If he didn’t, he’d license some game engine or technology, not spend time getting an AI to do the work.

    It’s an interesting interview, but it made me wonder how many people out there enjoy their work. How many want to go to work and get things done? Certainly, people want to get paid, but I would hope a lot of you have a job you enjoy doing, and aren’t necessarily looking to get someone, or something, to do the work for you.

    And how many go primarily because they have bills and need the paycheck? Would you rather be doing something else if you didn’t need the money?

    I love solving problems with customers, testing technology, and puzzling over the approaches to take when confronted with a challenge. I enjoy going to work, and while the paycheck matters, I like doing the work. I have no interest in retiring from my current job, as it’s fun. It’s hard some days, but mostly it’s fun.

    Do you still enjoy writing code? Or configuring and tuning servers? Or whatever you do? Are you looking forward to the day when you don’t have to do this job anymore?

    I don’t expect many people to comment unless they enjoy their jobs, but if you do, let me know.

    Steve Jones

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

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

  • You Need a DBA Pipeline

    I work regularly with a number of customers on improving their database change processes. This has been the goal of Redgate’s Database Change Management over the years, helping database systems work more like application software with DevOps principles. The idea is to move quicker and respond better to demands, while providing safety and governance. A database is a stateful machine, which is a challenge to evolve and maintain, but with good data modeling, testing, code analysis, and automation, your database change process can coexist with your application software.

    That being said, most of the solutions for managing database change focus on the database itself and everything inside it. After all, that’s where the data is. I understand people wanting to solve that problem, but there are plenty of things that need to be managed for a database server (or an instance for MSSQL) outside of the database. We have security, configuration, and, in the case of SQL Server, jobs. That might be the number one request is a way to manage jobs across systems.

    Regardless of any tooling you might use, the important thing that you need is a way to easily manage and deploy the scripts you generate. These might be adding users or logins, perhaps rotating certificates, or something else. Clicking through SSMS or manually running things might seem like it’s quick, but that’s a governed way to manage tasks. You might update a Jira ticket when you’re done, but do you always capture the code you ran in the ticket? The results?

    For many tasks, this might not seem like it matters. If we make a mistake, we correct it, and no one needs to know. However, this doesn’t help you work more efficiently, nor does it help your team work closer together. If there are records of the code and results in a pipeline, then you have a trail of who, what, when, and how. The ticket should tell you why.

    This helps hold you accountable. It ensures you test more carefully. It gives teammates a place to go grab a script that worked and re-run it, perhaps changing the name of something in the script; this allows the reuse of work. This ensures that the work is routine.

    Many of us have made a career out of doing work manually, and we’ve gotten good at it. However, the future will require us to work in a team, one that may include an AI, and learning to build patterns of work that flow easily across humans and agents will be a skill that lets us both be productive and provide value to our employers.

    Steve Jones

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

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

  • Designing for Teams

    Some years ago, I had to register for my medical benefits with Redgate. My employer had contracted with Anthem for health insurance, and I went to register myself. I found that not only could I not register myself, but there was already an account there with my tax number, and it was under my wife’s account. Many years ago, she had health insurance with Anthem through another employer. Anthem kept her record, which includes my tax ID. So today, in 2026, I have to log into my Anthem account with her ID to see my plan.

    That’s likely an older, legacy system, so we might understand that they didn’t expect two people to be primary account holders over time, right? Well, we also have a more modern tax software system to deal with. Let’s call the software “Chewit” to protect the reputation of the company. When we contracted with an accountant for services, they set up an account for me. However, my wife manages most of the money, so I asked them to add an account for her. Apparently, this “Chewit” business tax service only allows for one person in a household to have an account. This person has to manage the account, so now when my wife logs in with my account, I get a code, and I send it to her. If you think these are isolated, I have 3 or 4 other services that work like this, from well-known, global brands.

    The quality of data modeling and software development is depressing some days.

    A lot of what I see from customers at Redgate, often from people who want to use Flyway to smooth our their database change management, is that they have built similar solutions that often depend on A person (or A server or AN account) to work. Someone hasn’t modeled things well for teams. Even when we try to smooth out a flow, often I see the users don’t account for the complexities of teams working together. I think some of this is because a demo or a model often shows a happy path, and we all tend to think in that mindset of a simple flow. Managing parallel actions is hard, just like parallel programming is a thing many people struggle to do well. Well, they struggle to make the code work without race conditions.

    I see the same thing in T-SQL. So many people think in terms of singletons, working with a row of data. They don’t think in sets, or as Jeff Moden put it recently, about how to work with the entire column at once. Thinking that way is harder and requires a new mindset, but that’s why we get paid well. Or should be paid well. We solve the hard problems.

    The world is more connected, more complex, and more likely to require teamwork. Whether that’s between partners/spouses in a household or different groups of people in an organization. We should be designing and modeling for teams, not individuals, in everything from data storage and security to user settings and customizations.

    Steve Jones

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

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

  • Absolute and Relative References

    This week I caught a short tale of Reitse trying to migrate a Power BI report from one Tenant to another in Fabric. It’s something that I would consider a common practice, whether it’s from a dev tenant to a prod one, or from a consultant to a client workspace. Moving things around is what we do in the digital world, whether that’s schema structure, a report, a data export, or something else. This is common.

    And it should be simple, right? I’m not complaining about Fabric here, though it should be easier. I don’t know if this is a Fabric problem, per se, or maybe it’s a Power BI issue. After all, I should be able to decide and link things in a relative or an absolute manner.

    I’m going through this as we test some movement of the SQL Server Central infrastructure. There is a mix of relative and absolute pathing, which breaks the test system. This is similar to the issues I’ve seen when copying files and configuration inside a local machine. Should I really have d:\git\myrepo\flyway.toml, or should this be .\flyway.toml and assume the reference will be in the repo? There’s no easy answer, whether you’re using Flyway, Docker, or any software.

    This is a place where the user should think for a moment about the future and what makes sense. Every month I I attach a file from SharePoint to an email to my Finance group. Outlook always asks me if I want a copy or a reference. Often, for internal links I want a link, so that if I edit the file (or the recipient does), we edit the same file. However, in this case, this is a document of record, so I want to know what I sent, without edits. If I edit things, I want to resend it.

    Often we want relative references, especially in the Cloud and Internet places, where we might move resources around, and we don’t want breakage. This is common when moving from dev to test to prod, or from one server to another. However, at times, we want absolute references. On the flip side, I want a standard in my SQL Server instances that puts my data files and backup files in standard locations. Data on the d: and e: drives, backups on the z: drive was a standard we used in one place.

    I’m not advocating that you lean one way or the other, but think about the purpose of the item and the future possibilities. Sometimes an absolute reference makes sense, and sometimes a relative one works better. If in doubt, I’d pick the latter, but be sure that whatever software or system in which you work supports this.

    Steve Jones