Voice of the DBA

Category: Editorial

  • 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

  • Get Along

    I enjoy listening to Get Along by Kenny Chesney periodically, often smiling to myself. I was reminded of this song recently while talking about careers and the AI impact during VSLive San Diego.

    On one hand, most of the people I surveyed or chatted with were using AI to accomplish some tasks. However, very few are using it in a way that would eliminate their positions or do the majority of their work. On the third hand, lots of them worry about their organizations attempting to get by with more AI and less humans in the future.

    I think that last one is a natural point of view in the world today. I’m sure plenty of executives are hoping they can reduce their future labor costs with machine assistance. Quite a few are finding that the machine assistance isn’t that cheap, and humans are still needed. I don’t know where this will shake out in the future, but I guess that many of our organizations will shrink a bit and use less developers than they might have now. I also think there will still be plenty of developer jobs, but AI will be used judiciously to supplement the capabilities of workers.

    This means workers will need to know how to work with AI effectively and efficiently.

    Perhaps there will be new departments and new companies that spring up and create the need for more workers. I hope that’s the case, but I bet a lot of teams will lose some humans and replace them with AI. The cost of benefits continues to rise, and I don’t know that many companies will grow their businesses enough to keep all their humans and spend on AI. That’s adding lots of salary/token costs because of growth. Some organizations will have a lot of growth, but I suspect many companies will see that they have tasks that need humans and tasks that don’t.

    The common question from our discussions was “which humans will stick around?”

    Technical competency isn’t likely to be the deciding factor. You being a 10x engineer or the best coder might not keep you around. Spotting problem code and better guiding AIs will matter. The mentorship skills you use with junior staffers, and the patience, will become important. Some people are learning those skills now.

    The one thing most people agree on is that you should get along well with others. Those soft skills – the ability to communicate, being pleasant, making others feel not only comfortable but wanting to work with you – will matter most. If others don’t enjoy collaborating with you, especially your boss, I can see your position being precarious and potentially slotted for a layoff.

    This isn’t to say you can’t argue a point of view or debate an approach. The thing you should remember is that when you do present your view, it is seen as an engaging and spirited debate, not an antagonistic war. People want to work with others when they feel some bond with them. When they don’t, they might be indifferent or even dread interactions. Feeling dread, hesitation, or a reluctance to engage is a sign that someone isn’t a part of a team.

    Those who aren’t part of the team might be the easiest to replace with an agent in the future.

    Steve Jones

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

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