Voice of the DBA

Category: Editorial

  • Every Database Has Problems

    Every database platform has some strengths and weaknesses. Some more than others. I caught this site (NSFW) from Erik Darling, and it made my day. I was having a tough one when this site got me to smile and chuckle out loud a few times. I especially like the MySQL and SQL Lite links (again NSFW).

    Every platform that you might choose to use to back an application can work in many situations. Certainly scale and load are factors to consider, but for the major relational database platforms, most will work fine for many applications. Some might work better than others, but there are always tradeoffs. There are pros and cons. This is also true for the major NoSQL platforms, though most of my experience is with relational ones, so I tend to lean in that direction.

    At the same time, any platform can fail horribly.

    What’s the difference? Quality database design and software engineering. If you have a knowledgeable staff that works with the platform, they can likely make it work well. If they don’t consider the database impact when they code, or aren’t skilled with that platform, they can easily make it seem like the database doesn’t work well at all. Lots of hardware can help, but it often can’t outrun poor data models, poor query structures, or a lack of indexing.

    Quality of code matters, as many data professionals know. We often aren’t given enough time to do the job right, but we know that’s the case. It doesn’t do any good to complain or bemoan the fact that there is never enough time to fix things or improve them.

    We need to write better code to start with, which means learning to write better code. Understand what impacts performance, where you can change your patterns and habits. Watch Erik’s posts, learn from Jeff how to build test data sets to stress your queries if you don’t have good test data. Learn to do a better job in the same amount of time.

    Changing platforms won’t magically fix things, no matter what your CTO/director/manager thinks. Especially if your team doesn’t already have experience on the new platform.

    Steve Jones

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

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

  • The New OS Wars

    In the last year I’ve seen a lot of statements about data and sovereignty between countries. While there have been concerns in the past, there seems to be more worry around the world with AI services primarily being run by, and hosted by, US companies. Plenty of my customers at Redgate Software have concerns over our ability to see data when we run AI models, though we don’t store the data. Once the session ends, the data is discarded by policy

    Recently I saw a piece about France trying to rid itself of the reliance on US technology, specifically the Windows OS from Microsoft. They are looking to move to their own version of Linux, as well as a number of open source software packages. This quote was fascinating to me: “We can no longer accept that our data, our infrastructure, and our strategic decisions depend on solutions whose rules, pricing, evolution, and risks we do not control.”

    With AI being added to lots of software, including OSes, I suspect that other countries might look to follow France. I know the EU is looking to move, and Brazil has been trying to use more Linux and OSS for decades. While I find Windows works well, I completely understand wanting to move, especially in this era where many software packages are web-based and can run on a different OS.

    SQL Server runs on Linux, and half of my testing is on Linux, since I run SQL Server in a container on my laptop. My desktop still has a native Windows install, but I find it easy to port almost all code back and forth between the two versions. While I understand others might have a preference for PostgreSQL or MySQL or some other OSS platform, I think SQL Server provides a great value for many organizations. I also think it’s incredibly hard to port your software and data from one database platform to another.

    I do wonder if governments or organizations outside the US that look to leave Windows will also look to leave SQL Server. It’s one thing to move away from the OS and software like Office. A little training will get most users productive on a new system in a relatively short time. Moving a software application and its database is a much larger challenge.

    I expect SQL Server to remain incredibly popular for many years, and with the ability to configure the new AI capabilities to use your own models, I am not sure a country that wants to reduce their reliance on US technology will choose to do so for their databases. They will likely start elsewhere and continue to use SQL Server for years.

    Steve Jones

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

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

  • Working Better Under Pressure

    One of my colleagues wrote a great post about DBAs and developers, about how a DBA’s pushback on bad code isn’t to be difficult, it’s because they can see the future. I never thought of myself as a modern-day Nostradamus, predicting the future of system performance. Apparently I had another title besides DBA.

    Working under pressure and with short deadlines often leads to short cuts. I’ve made them. I’ve implemented quick hot fixes. I’ve forgotten to port changes back to development databases. I’ve increased our tech debt load, just to solve a more immediate problem.

    The challenge is cleaning things up later, when we have more deadlines and things to fix. It seems that we never have enough time to do the job the way we would like, and there’s certainly no time to go back later and fix things. Most management won’t make this a priority until things get so bad that we have to rewrite a lot of code (which we should never do).

    DevOps, pipelines, automations, and yes, AI, helping can reduce some of the tech debt we create if we use those tools appropriately. Which is a big IF. Often we have more immediate pressures that prevent us from finding time to invest in our systems or in ourselves.

    Getting a handle on bad code, checking it early, and doing so every time with automation can help prevent some of these issues, even when we are in a hurry. That’s why it pays to adapt our work and learn from others. Listen to that DBA that keeps your systems alive. Listen to the DevOps engineers that want you to automate things. Certainly, make them prove their suggestions work, but adopt those patterns. Learn to work with them, rather than against them.

    They can see the future.

    Steve Jones

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

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

  • Who is Irresponsible?

    There was a post on X recently from a founder in the EU about an engineer using Claude and ChatGPT to build a feature. I am not sure how true these posts are or if they are designed to just create engagement, but it’s still an interesting topic. The part that makes me think is that (supposedly) the engineer was fired because their “data” (code) was sent to American servers. The code was then deleted and the feature will be built without AI.

    First, read some of the responses before you form an opinion. There are some funny ones in there. There are a few I think are overblown and silly, and I skim past them. Someone is always more upset than I am, and more than I think they rationally should be, so I tend to let their outrage flow by me.

    There are two interesting things here. First, the debate about sending data to America. There certainly is some cause for concern here if data is being sent to a place outside of the EU where GDPR rules might apply. There possibly could be some legal issue here, though I doubt some of the responses about all code being compromised are an issue here. I don’t think code is PII, though if it were re-used or appears in AI output, perhaps investors could sue this company.

    The second thing here is whether someone should be fired for doing this. There might be a policy and some training about not doing this, and in that case, perhaps the person should be fired. However, I find this kind of thing happening too often, and it’s the type of thing that has happened before AI where people used outside sources (SQL Server Central, Stack Overflow, etc.) to post code in a question and get an answer. And then often use that code without changing or testing it.

    Is this rational? Some people might say yes, some no, many unsure. In the past, before AI, what would you think? To me, sometimes there have been solutions engineers have found but couldn’t use code written by someone else. There are real IP/copyright concerns here. You could rebuild the solution, rewriting the code, which in some sense is what Google did with Java APIs and successfully defended that effort. If another human or an AI gives you code, can you rewrite that code, keeping the same idea for the solution?

    I think that in most cases this is acceptable. I use AI for a lot of things and I throw away a lot of AI output, but it often gets me started down a path, whether in writing, coding, or something else.

    Who was more irresponsible here, the founder or the engineer? I think the former.

    Steve Jones

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

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