Voice of the DBA

Category: Editorial

  • Constant Azure Improvement

    This week I noticed a number of changes in the Azure platform from their change feed. Actually, every week has a crazy number of changes across the entire platform, but this week a number of these were related to data and databases. That isn’t always the case, but I saw some interesting items.

    We have zone redundancy for the general purpose tier of Azure SQL database, as well as AAD security principals in the master database and a new DMV for backups. I think Azure SQL Database is a great product, though one that has felt quite limited at times. The use of DTUs at first, the high pause period for Serverless and limited options at lower tiers were always annoying.

    The point at times seemed to be to get customers to place a big financial bet that a higher tier would meet their needs. I had hoped that some of that was just a blip in time as technology improved and more features would be deployed to all tiers. After all, the original Azure SQL database was a key-value store.

    That seems to be coming true as I continue to see improvements to the offerings. Azure SQL Serverless now has a 1 hour pause period minimum instead of the original 6 hour time. Now Cosmos DB has also lowered their autoscale offering. Cosmos DB can be provisioned at a lower entry point for autoscale, at 100RU/s instead of 400RU/s, which might get more people to experiment with a PoC over a bit of time and use the database. I know I’m thinking of trying to mess with some data on the platform. I don’t think I’d need 100 RU/s, much less 400, but I can better live the cost for a few months.

    Hyperscale has been an interesting version of Azure SQL Database. I know quite a few customers that aren’t sure if they need it, but they considered experimenting with it. The problem was that once you choose Hyperscale, you can’t go back to another tier. That’s quite a disincentive to experimentation, which seems to be part of the philosophy of choosing the cloud. There is now a preview of the migration of Hyperscale back to the general purpose tier. I’m guessing it took a little time for the Azure team to implement this, which is why there was a restriction, but it looks like that limit will go away.

    The cloud is an amazing place, as I’ve written before. It enables things to happen at a pace, and with ease that I’ve never seen in a data center without a lot of prep work. This week it seems that the Azure cloud advanced quite a bit in the area that I care about, the data platform space.

    There was also the general availability release of the Azure SQL Migration extension for ADS.

    Steve Jones

  • Your User Manual

    Many of us have spent time looking through manuals or the documentation for some software or product. I know I’m on the MS docs site regularly for work, and there is no shortage of times I’ve used various manuals to help me fix something around the house. We usually use a manual when we want to learn how something is supposed to work, or how to get it to do what we want.

    I saw a post on a personal user manual that I thought was a good idea for some people, maybe many people. This isn’t a manual for how you should live your life or work, but rather, how others might interact with you. This manual describes how you work, what motivates you, stimulates you, what pleases you, and even the environment in which are most productive.

    Whether or not this is something you might give to co-workers (or your boss), it likely is a good exercise for you to undertake personally. I do think this might be something you give out, but only if you have a lot of confidence it will be taken seriously and well received. Just going through the process, however, might help you better understand yourself, and you might learn something about what matters to you. Sometimes the things we think we like or want aren’t really the things that actually make us happier or more productive. I know I enjoy traveling, but too much creates a lot of stress. I like speaking in front of an audience but within certain boundaries. I like running, but my joints and bones will tell me that I really can’t have that in my life anymore.

    I’m going to make a quick, outline of my manual here. I like independent work, creative work, and the chance to decide how to do things. I like to work with deadlines, but without micromanagement. I want to be at home much of the time but go to an office and other places to interact with people periodically and regularly. I like working asynchronously most of the time, but synchronous brainstorming sessions are valuable. I like feedback to be written overall and with some thought and reasoning behind it, not a like/dislike/emotional response to my behavior.

    I think I could better flesh out different ideas with more detail and organize things better, but I enjoyed taking five minutes and thinking about my first reactions. Now I need to go back and revise this draft with a little more insight and consideration.

    Let me know today what you would think your user manual should say.

    Steve Jones

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

  • When to Use Zero

    I’m not great at building charts and graphs. I can build a basic chart, but I often depend on the tooling I use to size, scale, etc. appropriately for whatever I’m graphing. That, or I just use a basic graph that starts from zero and has some sort of linear scale. Or I just present a table of numbers.

    There are plenty of misleading charts, especially used by the media that want to show some particular aspect of data that suits the story they are reporting. Many of these misleading charts often don’t start at zero, and they end up scaling in a way that can confuse people.

    You wouldn’t think it was hard to decide whether or not to scale a graph of data from zero or not, but it can be complicated, as this post shows. There is a flowchart to help you decide when to include zero, or even when to have an inset chart that better explains the data. As many of us know, it can be easy to misinterpret data, especially when someone else is deciding what to show.

    In this case, the post talks about some examples of when the data doesn’t graph well because the scale is too large and the range of data too small. Or when the scale distorts the relative size of two values in a graph. In all of the examples, it makes perfect sense why you do or do not include zero on your axis, but I don’t know that I know when I should or shouldn’t do this.

    Part of the problem for me is that people often glance at visualizations and charts without spending enough time to really study them. That’s part of the idea of a visual, in that we can get information quickly from a picture, as opposed to a chart of numbers. However, it is still easy to look at a broken scale or inset chart and not spend the time to comprehend that one value isn’t twice another, but instead realize the chart is zoomed in because the scale changed. There isn’t a perfect way to present information, but there are ways that might work better.

    To me, a lot of misunderstanding gets cleared up when we discuss the chart and the data in a group. Often one person will realize when others are not reading the scale when drawing their conclusions and remind others that Canada isn’t twice as large as Brazil. That works if people speak up and if others listen. That isn’t always the case, especially when the boss is making a mistake. The other issue is that many of us might look at a chart by ourselves. and we are unlikely to tell ourselves we are misreading the values.

    There isn’t a good way to ensure people read a scale and factor that into any decision they make regarding the chart. I do always like to include some data with a visual, that way I can see raw numbers on the same report, or by drilling in. The combination works well for me, but I’m a geeky, numbers person. I like seeing data, which is why I like working with databases.

    Steve Jones

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

  • Moving Away From MySQL

    I like SQL Server as a database. I think it’s very complete, solves most of my problems, and is easy to use in work. It costs money, but less than some others. It’s also more complete to me than some of the open source databases out there. That being said, I think most of the top five or six relational platforms would work for me and I wouldn’t hesitate to use them.

    I ran across a post from Steinar Gunderson, who worked at Oracle on the MySQL team. It’s on his last day there, and it’s a bit of a why did he leave. I like that he notes he found a better opportunity, but he digs in deeper. Why did he look for a new opportunity?

    The answer seems to be that MySQL was a shockingly primitive piece of software, according to him. He felt there was lots of room for improvement and change, but people seem to like and accept what MySQL is and does. He is proud of what he has done, but felt that this was a product that was vastly inferior to other database platforms.

    That’s interesting, because I think MySQL works fine and is in use in many situations. While there might be plenty of things that can be improved, I’m a practical guy. If the technology meets my needs, and those I can foresee, I see no reason to change. That being said, I wouldn’t reach for MySQL to start a project. If it wasn’t SQL Server, I’d lean towards PostgreSQL.

    There are a couple of examples in the post, and it’s certainly a good post to write on your last day. If you published it when it wasn’t your last day, it might quickly move in that direction.

    If you use MySQL, I’m curious what you think. If you don’t, would you if SQL Server weren’t available? Would you learn MySQL for a new job? Or are you a die-hard, this is my platform kind of person?

    Steve Jones

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