Voice of the DBA

Category: Editorial

  • 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.

  • Poor Names

    It’s always interesting to me when I give product feedback to engineers at Redgate on their demos. Quite often they’ve built a feature that uses AdventureWorks or Pagila (PostgreSQL) or some other well known schema to evaluate how their particular thing works with a database. I try to remind them that many databases aren’t well modeled and designed with consistent naming.

    I ran across a Daily WTF article that isn’t showcasing databases, but it does show some poor naming in data being stored in a PDF. The developer who had to automate a process had to map these fields to database fields, which also might not be named very clearly. In fact, I think I’ve seen a few database models that used column names like the field names in the PDF.

    Most systems we work on evolve over time. They aren’t built by one programmer, or one team, across any period of time. Existing developers leave and new ones start. DBAs change, and we often don’t have any code analysis rules enabled or running in CI that might help us with consistency.  Often we don’t even have our rules documented.

    Humans are amazingly creative beings, but they also get very uncreative when they have to repeat that creativity over and over. It’s why we find a neighborhoods in Colorado with Pine St, Pine Ln, Pine Rd, Pine Circle, Pine Way, etc. You get the idea. Someone got bored and didn’t want to be creative, so they just took the easy way out.

    The same thing happens in databases. I’ve seen people have a Customer table and then a CustomerDetails table alongside it (singular and plural) with a custDefault (case) and a tblCustContact (prefix) table that leave me scratching my head. Did the next developer not look at the database at all? Certainly they didn’t use any modeling tool like Redgate Data Modeler.

    I don’t blame others, since I’ve found myself struggling to be creative as well as consistent when I build systems. Sometimes I’ve got some automation running that reminds me to do better, but often I’m depending on another human to catch these inconsistencies in a code review. However, I’m not sure code reviews include looking at the name of the object for most people. Well, maybe column names, but that might be it.

    I’d hope an AI system could recognize poor names and then suggest better ones that capture the intent of the data being stored and look like the other objects in the database. Unfortunately, that will likely lead to a section in the database that looks amazing while all the older objects drive you crazy with their random nature. Maybe the AI can at least update the comment or description fields in code to ensure there’s some place to look for information to help us do better in the future.

    Steve Jones

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

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

  • Acting with Confidence

    Recently, I saw a graph about making decisions that showed the impact of both reversibility and consequences. Here is an example of such a graph and how one might approach decisions. If things are easily reversible or have a low consequence, we tend to make a decision and move on. Or we are willing to make a decision. One of the examples of such a decision was choosing what to wear out to dinner. It’s easy to change, and (in general) of little consequence. Choosing to send a large amount of money to someone through Venmo (or some other mechanism), can be hard to reverse and have substantial consequences.

    This made me think of some of the DBA and developer decisions I’ve made in the past. When we work with databases, the changes we make can have a large impact and be quite consequential to our organization. Downtime, data quality, etc. could all impact revenue, profit, reputation, or even future prospects of survival. That can be a lot of pressure when you are deciding to refactor a data model or adjust a lot of data during a deployment.

    We might think we can rollback or undo changes, but often we would end up applying reversing transactions. If I change a data type, the data is changed ( assuming the DML completes). To change back, I can’t roll back outside of a restore. I would change the type back and have an equally large and long transaction run. Having HA or replication technologies in the mix can dramatically impact the scope of both the initial and reversing transactions.

    How confident must you be in your actions before you undertake something of consequence? Do you require an easy rollback, or are you willing to act even if the rollback is painful?

    Maybe a better question is how do you appraise the consequence of an action? Is it the application/database or perhaps the data? You might consider all the dependencies from other applications or pipelines on this. I know many DBAs worry about the performance impact of changes that can slow or stop other work. I constantly see people asking if Flyway can estimate how long a change will take, especially when dev/test environments are a poor representation of production sizes, scales, and workloads.

    If you have a 2GB database, you might just make changes. A restore is quick, and I’ve often found greenfield applications taking this approach since the data sizes are small and even consequential actions can be undone with a restore operation. Many of the “code-first” technologies work great in these situations, but once we have multiple application dependencies and large data sets, restores can be non-trivial or even unacceptable ways to deal with issues.

    The image linked above talks about gathering data and analyzing, which sounds like the prudent thing to do, but this can be easier to say than do in practice. Deciding what analysis to undertake and how long to spend on it are the real tricks. Those are the judgment calls that only experienced humans can make. While AI might help, this is an area I really want capable humans with the final say.

    Steve Jones

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

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