Voice of the DBA

Category: Editorial

  • AI Concerns

    I hosted a webinar a few weeks ago about Artificial Intelligence and how it might affect data professionals. It was an interesting discussion with Kellyn Pot’Vin-Gorman and Brian Randell, with all of us having slightly different perspectives. Overall, we all agree AI is amazing and can be a useful tool for data professionals.

    This week I’ve been in Redmond at the MVP Summit, and AI has been a topic among many MVPs. Lots of jokes have been told, no shortage of which dealt with getting rid of staff. Not that these MVPs want to see less staff, but they know that executives and managers might see all the AI hype about how GitHub CoPilot writes code and think they need less developers.

    I don’t know if that is really how executives will view the world, especially as most IT departments have more work than resources to complete their list of tasks. I can see AI helping get more done, which might mean less hiring (or slower hiring) in the future.

    There was an article this week talking about ways to protect your job in the age of AI hype. It was interesting in that the suggestions all revolve around bringing more value to your job. The suggestions about working in specialized areas, complex areas, being a better employee with documentation, these are all things that I’ve done in my career. It’s what I also see from many MVPs.

    Maybe the most interesting item was to think about incorporating AI into your work now. It’s not necessarily an expert on your work, but it is a tool. As the models absorb more information and become better trained, they can be a level to help you get more work done. They can assist you in tedious work, which is something many of us can benefit from.

    I am looking forward to getting access to CoPilot and keeping an AI tool up on my desktop, learning how it might help me, and maybe more importantly, where it won’t help me.

    I can’t stop this trend, but I can better understand it and learn how it might fit with my daily work. Knowing that helps me better understand how I might have an informed and rational discussion with management about the advantages or disadvantages of this new technology.

    Steve Jones

  • A Third Break

    One of the most amazing benefits of working at Redgate Software is the ability to take a sabbatical every five years. One of our staff wrote about this recently, and I found myself reflecting back on mine, as well as thinking forward.

    The article notes that many people either learn or travel during theirs. That was somewhat of my experience, where I spent my first one learning skills and volunteering at home. My one-year look back is still interesting to revisit today. Unfortunately, my flagpole base failed in strong winds (sad face) and broke the pole. It’s still on my list to rebuild a new one. I still look back on my volunteer time with fondness and try to get back to Habitat every year.

    My second was avoiding travel, since I’d traveled a lot the year before. I ended up with the last sabbatical before the pandemic, coming back to work as our office closed. I stayed home, worked on learning and projects, though I did take a trip to Las Vegas to celebrate my wife’s birthday.

    Six weeks away from work seems like a lot. Before Redgate, I’d have thought that this was a huge burden on the employer and fellow employees. However, we’ve had multiple people on sabbatical and we cope. We pick up the slack, and things continue to run. As with maternity (and paternity) leave, it’s not as big a burden as this American used to think.

    It is very refreshing, and each time I’ve felt rejuvenated. I’ve been ready to get back to work, talking with Redgate customers and speaking at events. To me, this is a great way to encourage retention among loyal employees, as well as a way that can create more diversity of thought among your employees. Where they travel, the things they learn, even the change of pace in their mind often bring them back to work with new perspectives and ideas.

    I just crossed my fifteenth year at Redgate, so I’m due for my third sabbatical. I haven’t thought about it, and I am not likely to take it this year. This does take some planning, both in my personal life and at work, so I have found I usually need 5-6 months to decide on something and get plans in place.

    What will I do this time? I’m not sure. What would you suggest? I am thinking to travel this time for part of the trip. My wife and I had an amazing travel time in 2022, and there are so many amazing places in the world that I’d like to visit. I am also tempted to try and fit in some learning as well, perhaps a week spent in some sort of educational endeavor.

    No matter what I decide, I am grateful for the opportunity and look forward to another break that helps my work-life balance, balanced.

    Steve Jones

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

  • Data Modeling Information

    Data modeling is something that we should all be doing when altering the schema in our databases. I’d like to think that most people spend time here, but I don’t think that’s the case. I think plenty of people think “I need to store a piece of data” and they pick a string or numeric datatype and start stuffing in values. If in doubt, just pick a string. It’s why I think we have lots of dates stored in string columns because that was someone’s first thought.

    There was a post recently that talked about storing data in its highest form. It was interesting to me because these are the type of decisions I try to make when designing a table. What is the best form in which to store data? The authors talk about picking not only a type that easily converts, but the fields that make it easiest to work with the data in different ways.

    I do think that the aggregations or calculations that we need to perform should influence your data type. If you are measuring something, use a numeric. In fact, in their example of movie times, integer is probably the best type. While many databases and languages have time datatypes, some represent a measure of time (timespan), while others represent a clock (T-SQL time). Either might work for movies, but in aggregations, the T-SQL time will have issues beyond 24 hours. An integer is a better choice, assuming we don’t care about seconds.

    The second part of the post looks at multiple values, in this case customer loyalty points earned and redeemed. A simple running sum is what we might store in a database, though the application class might need two fields. Of course, modern software often totals these things for a customer as part of gamification and inducement to engage more, so maybe a data store would also want to store the title earned and redeemed, with a calculation to show the balance.

    The one thing that I might add for developers to a post about modeling is the need to consider operations at scale. While using a bit more or less storage often doesn’t matter for any row or any operation on a singleton set of data, when we scale across millions of rows, little things matter. Consider how your data might be aggregated and what happens if you have millions of rows to work on. There a better design decision can out perform a poor one by many orders of magnitude.

    That and generate lots of data to test. You ought to know how to quickly mock up a million rows to check your queries. You might have a million rows in production.

    Steve Jones

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

  • Coming Out of the Cloud

    Google has launched a version of their AlloyDB that can be installed on-premises. AlloyDB is a PostgreSQL compatible cloud database, a full-managed PaaS service. However, they are giving away a free developer edition and a paid for commercial license that can be installed where a customer wants to run it. The new product is called AlloyDB Omni.

    I like Google’s approach here. Obviously Google would prefer lots of their customers would move to the cloud version hosted in GCP (Google Cloud Platform), but they know that’s not realistic. Even for customers that want to move to GCP, the customers might need to keep some workloads on-premises for a period time, so Google is giving them an option to modernize their workload with a new datastore that is PostgreSQL compatible, but running on-premises. Presumably this will be compatible with the cloud version and if customers want to, they can just shift to AlloyDB.

    This is similar to what Microsoft is doing as Azure SQL versions, both  database and Managed Instance, are mostly compatible with SQL Server on-premises. There are easy migration paths, but since the cloud and local versions aren’t quite the same, it might not be simple to migrate. There are lots of tools to help, but the biggest problem (in my mind), is having a development environment that mimics what I get in the cloud. I need to be able to work not only offline, but with the unlimited CPU I get on my laptop. I don’t want to pay for developers to stand up cloud instances to experiment with code.

    There is the SQL development container (running Edge), but that’s a container and I find far too many people don’t like working with the container versions. They struggle with getting their data set in the container, or keeping it up to date. Plus there’s the fact that the local environment seems linked to database projects, which not everyone uses. Especially those of us using Redgate tooling.

    I have been surprised in the last five years by how many companies have moved to the cloud. I’m especially surprised how many have performed lift-and-shift migrations to IaaS services after a mandate by management. I’m also not surprised that many customers find they’re spending too much, and that both Azure and AWS realize they need to help customers spend less before they lose them.

    The cloud can be a good place for workloads, but you need to plan for it, and often you need to modernize apps, make them less chatty, and write better code against your data services. To do that, I think you need a local dev environment and I like the way that Google is providing that with AlloyDB Omni. I wish we also had a switch to get a local SQL Server dev edition to act like Azure SQL DB.

    Steve Jones

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