Voice of the DBA

Author: way0utwest

Stacked Bar Charts vs. Line Graphs–Which is Better?

I ran across an interesting post from Rita Fainshtein that looked at the different types of graphs for a set of data. I thought that was interesting, so I ran my own experiment. I found for my data, a line graph was better, but let me know what you think.

My data set was simple, a few players across a few events and their number of kills. I coach volleyball and I’m always trying to present stats in a useful way. Here was the small set I picked.

Nothing fancy, but this is similar to what was in the article. From here, I asked EXcel to insert a chart from the Recommended Charts and picked the first one. This is what I saw:

This isn’t bad, though it’s hard to compare across events. I see how A did for all these events, but if I want to see if she was better or worse than K, I’m guessing on some of the lines.

Next, I opened Power BI. I added my data set and then dragged a value to the visualizations. The default chart I got was similar to Excel. Not a great visual. It’s Ok, but suffers from similar problems.

I moved the player and the event from the axis to the legend, because that’s more appropriate for this dataset.

I changed the type to the first stacked chart I saw, and got this, which I think isn’t useful at all. There isn’t a way to measure 100% in this case, so normalizing all data in this way is very unhelpful.

I switched to a normal stacked chart, which is OK, but for Crossroads, is A or K better? Does E outperform A in Aurora? Very hard to tell.

Next I tried a line chart. This I think is the best for my analysis. I can see the events across the bottom and the colors for the players make it easy for me to compare them with each other. I am not color blind, so this works for me.

I can also compare the players individually across events by following the lines. I can see them all trending in similar ways, which is expected. If the team does well, everyone does better. If not, then not. I also see the outlier where E outperformed A.

Summary

The line graph worked best for me. However, the data I am looking at lends itself to a comparison that looks good here. The stacked bar chart isn’t as clean when drawing conclusions, but that’s because I’m looking at the different segments across items, not necessarily with segments for the same item. Of course, I think that would be hard as well.

Ultimately the data you are analyzing and how the analysis is used will affect what you think is better. Work with the people who use your visual to make a decision and let them help guide you for the best visual.

In this case, A loves seeing she’s ahead almost all the time.

May 22, 2023
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.

May 22, 2023
A New Word: Trumspringa

trumspringa – n. the longing to wander off your career path in pursuit of a simple life, which is just the kind of hypnotic diversion that allows your thoughts to make a break for it and wander back to their cubicles in the city.

Such an interesting word. I know I had this when I was working at JD Edwards (and later Peoplesoft) in Denver. My wife certainly had it. In some sense, she’s made this come true and it’s no longer a longing. It’s semi true for me, though I still work at a desk.

Coping with stress and struggles have had me often thinking what else could I do. I still do this a little, though not more than just as a diversion since I have a great job. More now I look to find ways to actually wander away and try something new.

From the Dictionary of Obscure Sorrows

May 19, 2023
Speaking at SQL Saturday South Florida 2023

I have never been to the South Florida SQL Saturday. There have been a bunch of events, but for some reason I’ve never been to one. I was excited when I saw this event planned and the date worked out.

I found out that I was picked and I accepted. Now I need to plan a trip and get organized.

I’ll be talking about Database DevOps, so if you can get to the Miami area in early June, I’ll see you there.

May 19, 2023