Voice of the DBA

Category: Editorial

  • Being Mindful of Design Time

    Over the last few years, I’ve worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code.

    In many cases, however, what lots of management wants is speed, and they’re looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone’s goals.

    However.

    What I see too often is that both their current process and the new one are often lacking fundamental database design and modeling. Developers aren’t well-trained and make design decisions based on an (often) incomplete spec. They alter schemas to fit the immediate challenge, without thinking about the future. Good database modeling considers the often unasked questions and unspoken rules of the problem space.

    Moving to a smoother process that allows code to be merged, tested, and released in a quicker fashion is great if you are writing good code. It’s less great if you aren’t. Most of us have a lot of poorly architected schemas and don’t need more challenges from more bad designs or bad code.

    I wonder how much time most of you spend on database modeling? Do you try to out more than one design? In this podcast, John Ousterhout talks about designing a system twice. He tries to get his students to come up with a second idea for a problem, which often brings out a better design. I wonder if this might not be a good idea for database modeling as well.

    I’m sure most people do their best to build a good data model, but experience often teaches us that the way we decide on a table structure, data types, keys, indexes, and more changes as we learn more. Our experience can help us make choices that perform well over time and don’t limit flexibility.

    Is design an important part of your development process? Do you have guidelines for your organization? Do you consult more experienced database people? Or to inexperienced people ask you to review their choices? Building a more efficient software development process should help you to move code to production more smoothly, and therefore quicker, but it shouldn’t be used to deploy more poorly written solutions. Take the time needed to implement well-designed and tested code, including your database code.

    Steve Jones

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

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

  • Internal Staff Growth

    Imagine that you are about to tackle a new project that will take more than a year. This might be a new system, perhaps a cloud migration, or maybe it’s rewriting something that doesn’t work well. You don’t have enough employees to undertake the project without overloading everyone. Your team needs to grow.

    Would you rather hire a more senior person from outside the organization or pick a junior person that’s already inside your company and teach them what they need to know? Think about this as if you were the one making the decision about the future direction of your software team. Philosophically, do you want to buy experienced people or train/build new ones from your internal staff.

    It’s an interesting idea and for a lot of companies, I see them looking outside the company first, rather than investing in, and training, their internal staffers to grow. It takes time to train and grow people, for sure, and it’s a constant investment that never goes away. At the same time, bringing people in from the outside also requires some level of training on how the current systems and org work, even if the new hire has a lot of experience.

    I think there are good reasons to look at both of these, but my view is that I want to have people on a team that know how to work together. The tech skills (or design, modeling, etc.) can be taught, and I would rather have a good cultural fit, already knowing how a person fits with others. That assumes I’ve got good employees who fit together and believe in our culture. That’s hard enough to do, which is why I want to hire people who can work as a team and keep them. Part of the “keeping” them is investing in them.

    This also means that if people don’t fit in, I want to help them move on to a better fit.

    This doesn’t mean I want everyone to think the same. It is important to have a variety of views on how to design and build applications. A variety of people is important, but we have to be a team.

    I prefer to train and invest in the people I have over bringing in more experienced staffers. A big part of why I feel this way is that hiring is always a gamble, and it seems we make no shortage of mistakes. If I do get it right, then I want to grow and keep those people around for the long term.

    Steve Jones

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

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

  • Do You Really Need HA?

    I ran across a thought-provoking post from Chrissy LeMaire asking if we should reconsider SQL Server HA. The post actually asks if you’ve considered not using it. The default from Chrissy, for most installations, is to use standalone SQL Servers. This isn’t to say she’s against HA solutions (FCIs or AGs), but that they often cause problems and might not be needed.

    It’s an interesting position to consider. For a long time, I avoided SQL Server clusters as they were hard to setup with a lot of complexity, hardware requirements, etc., and didn’t really provide enough benefits over using log shipping with a second server for me.  These days I have clients with mostly AGs, and they seem to run fine. That being said, Chrissy notes that after she left a job, a network outages caused a bunch of downtime. I could see there being downtime, as the old database mirroring (and the it-will-never-die replication) needed a working network. If you have network issues, you better know how to manage your HA technology’s issues.

    I also Brent reposted this on LinkedIn, with some fun comments. There was one great one, which said, “Can confirm. FCI is literally my friend’s largest downtime cause.” That one got me to stop and think a bit. If I were having stability issues with any of these technologies, I’d certainly look to replace them. I value my time off and my sleep.

    I know people who default to using AGs with most servers, mostly to avoid someone calling when a system is down, but to be fair, I also think these are some of the more talented data people I know, so perhaps they can handle minor issues and prevent them from turning into major ones. However, Chrissy brings up a great point. SQL Server HA (or Oracle, PostgreSQL, Linux, etc.) isn’t simple. If you have staff turning over, are they qualified to keep things running?

    Or do things just happen to run without these people until something breaks?

    There is also the RTO issue. If you have a high RTO, like a day or two, is HA worth any amount of effort? Isn’t it better to rebuild things and restore? Especially in the cloud, where I might be able to redeploy a new VM/db/etc. and put data in it? Note, I’d want to be sure that I can get to my backups. The SLA on getting older files might be slow, and if it is, I’d want separate backups.

    I do think that small to medium companies ought to rely more on backups and tools, like dbatools, to provide the ability to recreate a system. Adding in the complexity of HA certainly shouldn’t be the default, especially if you aren’t sure the staff will be around for the long term. The caveat with that might be if you use a company like ProcureSQL, StraightPath Solutions, Dallas DBAs or someone else, maybe you don’t worry about staff turnover.

    Steve Jones

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

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

  • Poor Name Choice

    I wrote recently about some work with Redgate Clone, and one of the things I did was start up a blank container instance of SQL Server from the image named empty-sql-current. This image contains SQL Server 2019. Clearly, “current” was a poor choice.

    I see this often in various places, where someone will reference “current”, “new”, “latest”, or some other term that denotes the most recent changes. If everyone reading the reference is doing so with knowledge of the past and at a time close to publication, this works fine. However, a year later, does this make sense? At the same time, I do like consistent names that might be used in scripts. If I always want developers pulling the latest item, I might use latest. However, if versions are important, than “latest” or “current” might not be the best choice. Much of the time, I tend to try and get a version or some other specific indicator in a name.

    It’s like seeing the words “the fastest SQL Server ever” (or pick your technology) in a release announcement. At that time, it might be the fastest SQL Server release, but when the next version is released (hopefully) that won’t be true.

    As I’ve matured, I aim to build things that last for the future, thinking beyond what the world looks like right now. This includes architecture decisions and more, but it also includes naming. Reference specific versions, times, etc., with the idea that I want to convey some information with the name. I even name my containers with the port I use because it makes it really easy to see which database container is running on 1433 and which is 41433.

    The other consideration for naming, for me, is to include data in the name that I will use for searching or sorting. Perhaps means using good date practices, like 2025-05-01 and 2025-10-03 to ensure my files sort correctly. That might be very important for things like backup files. Maybe it’s using something like “Customer_Copy_Delete_After_Year_Close” for a copy of data that might be relevant through our current financial cycle.

    I often do like using names that come to mind first, as this can help me find things, but I also have learned to be more explicit when using names as a way to convey information. With modern computing and support for large names, it sometimes pays to be descriptive.

    The only thing I try to avoid is spaces. For the most part, file explorers and web servers handle spaces, but sometimes things break, so I’ve learned to avoid spaces where possible.

    Steve Jones

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

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