Voice of the DBA

Category: Editorial

  • The Best Graph

    Conveying information is a bit of an art and science. Many of us have written reports, graphs, charts, etc. at some point in our career. We’ve likely created some good ones and some bad ones that our clients love or hate. Perhaps if you’re like me, you make a small attempt and then ask someone else to clean it up for you.

    However, visualizations are important. In the modern world, many people want a visualization instead of a table of data, or at least alongside a table. That means we want to ensure we are conveying information well and not just picking the prettiest picture.

    One interesting thing to consider is how different types of graphs affect how we process information. There was a post from Madiera Data that looked at how different graphs helped someone analyze the data. It starts with bar graphs, which have been very popular in the last few years. They are appearing in lots of business dashboards, news articles, and more. They can be useful in some situations, but not all. Especially when trying to compare the different segments.

    Instead, other visualizations can be better. The article shows table graphs are working well. I conducted my own experiment with visuals, and I found a line graph was easier to use. However, that was for my data. Your data might need different visuals if you use it differently.

    I don’t think there is a best graph, but there can be a best graph for a particular data set and a particular client(s). The way someone makes decisions based on a visual could dictate what works best. That’s my advice: work with your clients.

    For good general advice, I think you should lean on https://www.storytellingwithdata.com/, Meagan, and resources such as Edward Tufte, who have spent a lot of time thinking, experimenting, and understanding how to convey information visually. You could learn a lot from them.

    Steve Jones

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

  • Database APIs

    Creating an API and using an API server of some sort has become a very common way of working with modern software, especially distributed systems. Whether developers move to microservices or something else, they often make more use of APIs than ever before. At Redgate, I’ve watched us work on new products, often beginning with a basic API at the command line and evolving from there.

    However, does the database need an API? This article thinks so, though I don’t love the piece. It seems to wander a bit amongst a few topics and doesn’t always fit together. It’s also trying to promote the Stargate API gateway for Cassandra. I don’t know if this is a good idea, or if it really helps make developers more productive, but the idea of having an API for developers makes sense.

    In fact, when I work with clients I often try to get them to think of their tables as an API of sorts. With APIs, we want to rev them, but carefully. After all, we know there are dependencies from various other pieces of software, including other items inside the database. We want to be sure we don’t break anything. At least not for long, which is why DevOps and being able to release work quickly matters.

    Communicating changes and coordinating work is a challenge. I was surprised by a client who used SQL Doc for this reason, to ensure everyone had up-to-date knowledge of what their schema meant. It’s also a reason I’ve taken some of the work I do with clients and built my Architecting Zero Downtime talk. Many developers think narrowly about the requirement in front of them and not about all the other dependencies and impacts. I think a bit more unit testing in databases would help here. In fact, I demonstrate sometimes how to write a test that treats your table like an API to prevent breakage.

    I do agree that databases, especially relational ones can be complex. If we can simplify things for developers, especially developers new to our system, we can get more work done and hopefully, raise code quality. I don’t know that Stargate or GraphQL or anything else is better, though I have started to think LINQ is a better implementation than SQL for working with relational databases. That’s not going to change anytime soon, and plus, I need SQL to remain popular until I retire 😉

    Whether you formally build an API or not, it is helpful to treat your schema like an API and make changes in the same way that you would if there were other teams depending on your interface. That’s because there likely are others who depend on what you build.

    Steve Jones

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

  • Watashiato

    watashiato – n. curiosity about the impact you’ve had on the lives of the people you know, wondering which of your harmless actions or long-forgotten words might have altered the plot of their stories in ways you’ll never get to see.

    I found this word in the Dictionary of Obscure Sorrows, which is excerpted at this site. This book includes new words that describe emotions in great depth. One of the descriptions was the word above, watashiato. Of the few dozen I read, this was the one that stood out to me, and it’s something I’ve experienced. Maybe more than just being curious, though.

    As someone that does a lot of writing and speaking, I know that my words and actions have an impact on others. I’ve had many people write to me or tell me in person that I’ve affected them. Usually, this is very positive, and I’m grateful for the kind words. I am proud and happy for the positive impacts I’ve had in people’s lives.

    However, I know I must have had negative impacts. I’m sure I’ve written or said something incorrect that upset someone, or messed up their day at work, or perhaps caused an outage and they had to work late. I hope I haven’t gotten anyone terminated, or even chastised from management for something they learned at SQL Server Central, but I don’t know. I try not to dwell on this, but at times I think about whether or not I’ve changed someone’s life for the worse.

    I might have treated someone poorly. I know I did early in my 20s, as an arrogant young man, but I’m sure I’ve done things that meant nothing to me but affected others. Perhaps even deeply.

    My life has gone well, my career is a success, and I am grateful for that. I try to appreciate the small moments in life, and embrace dés vu (the awareness that this moment will become a memory). My wife had trumspringa and made it come true, leaving her corporate job to train horses. I’ve watched others do the same thing.

    These days my goal is to live my life in a way that makes the world better. I work, I need a paycheck, but I try not to be driven by that. I appreciate time with loved ones and experiences. I appreciate the conversations, the handshakes, and the hugs. I look to enjoy the laughter with others and the hard times, appreciating them as a part of life. I try to leave the world a little better than I found it, and hopefully, lessen the chances of future sorrowful watashiato.

    Steve Jones

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

  • Encouraging Innovation

    I was working with a client recently and one of the managers said they wanted to encourage innovation inside their organization. That sounded good, but as I thought about it, I wasn’t sure what this means, or if it’s really something that matters. Let’s take a few examples and think about this in a modern organization that builds and operates software.

    If I am a developer, I get a series of requirements or tickets where I have to write code. Perhaps I need to take inputs from a user, query a database, and produce a result. I might write code in C# 7 instead of C#6. Maybe I’d use a lambda instead of creating a new function. Perhaps I decide to ensure I use the stored procedure type with named parameters rather than submitting SQL as a batch. Is that innovative? It might be a better way to write code and improve the quality (or security or maintainability) of the code, but is it innovation?

    Another example. I’m a DBA and I need to run scripts against production. All the DBAs use SSMS, but I decide to change. I store the scripts in a folder and use Flyway to execute them against production with an automated system like Octopus Deploy, which manages the security. Is that innovative or just adopting a more DevOps-y practice?

    Jason Fried says innovation is overrated, which I think is true. At least when that’s an aim or we expect to build something radically different. I know there are sometimes we might come up with something new that our organization hasn’t done, but most of the time work is work. It’s tedious mundane, and it can be very repetitive. That’s why the urge to do and try something new pervades most development organizations.

    I do think that you can regularly innovate in your workplace. You might not create something that’s never been done anywhere in the world, but you might get people in your org to try something new. To adopt a new technique or habit, to create higher quality code with a small change. That’s the type of innovation that I like to see and foster. That’s what DevOps encourages, experimentation and learning. It’s also what I think my examples above show. It’s innovation in this particular space, which hopefully makes work more interesting and enjoyable.

    Steve Jones

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