Category: Editorial

  • Refactoring SQL Code

    One of the things I see software developers often talking about is how they refactor code. As they touch a class, method, etc., they may take the time to refactor the code to make it cleaner, perform better, or just add some documentation. It seems that a regular part of a software developer’s job is refactoring code in the codebase.

    That is unless they see a “don’t touch this, no idea how it works” comment. There are plenty of those, and often everyone leaves that code alone.

    I was thinking about this when I saw this article on strategies to refactor sql code. The article seems written more for PostgreSQL, but there are items that relate to T-SQL as well. The main thrust of the article is about trying to rewrite code to DRY (don’t repeat yourself). The more changes you can make to shrink code, either to make it easier to read or avoid repeating those copy/paste items, the better off your team will be. It’s easy to think those copies aren’t a big deal, but it’s easy to update code in one place because that solves the problem you were given, and forget to fix all the copies.

    I don’t know that anyone should implement all the techniques listed, but they are things to think about. Using CTEs, Views, APPLY, the WINDOW clause, and more can help improve the health of your codebase and make it easier for all the members of your team to understand how the system works.

    I wonder how many of you have a refactor mentality when you touch code, or do you tend to leave things alone and add new queries/objects/etc. to your database. I wonder if the fear of breaking something that might be used by other code is on your mind. Or maybe you suffer from “not invented here” (NIH) and just add your own code.

    If you refactor code, then what things do you look to change or improve? Any tips/tricks/guidelines you’d share with others? If you don’t refactor code, why not?

    I think testing is a big part of refactoring. If you have tests, then you can be less worried about your changes breaking something. There is a great video on practical refactoring. It’s from the software engineering view, and it’s long, but it’s worth a watch if you have a few moments.

    I wish more people tested their SQL code and refactored poorly written (or poorly performing) code on a regular basis.

    Steve Jones

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

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

  • Investing for AI

    The GenAI boom is growing like crazy. From hype to disasters to successes to investment to the embedding of GenAI tech into lots of products, it seems no one gets away from AI. My wife, kids, friends, they all talk about AI and alternately give me stories of huge successes or epic failures. Even those who just scroll through reels aren’t immune as we see amazing things, but we can’t trust them because of AI. Who knows what image/video/audio was actually recorded and what was generated.

    Like many of you, I think AI can be amazing. Like more of you, I think it can be a really poor partner and it produces output I can’t trust. I think one of the major challenges is learning to treat an AI like a colleague whose work quality is erratic. It’s not that I can’t work with them and use their work, but I need to test, validate, and verify the code they give me does what I need, at some acceptable quality level.

    Microsoft is a company investing a lot in AI, and it’s changing the company. Some of us might not like the direction as it seems that AI is being pushed for the sake of AI and to generate profits for Microsoft. Or at least revenue as I’m not sure how much profit there will be with all the compute costs of AI. However, it’s certainly affecting every product development team.

    I listened to a very interesting interview with Satya Nadella talking AI, globalization, and more, including a data center tour of their new AI site in the ATL. The data center tour with Satya and Scott Guthrie is at the beginning and it’s amazing to see. The network connections in this data center are equivalent to all of Azure a few years ago. That’s impressive, especially seeing they plan to link these new generation data center with petabit networks. For someone that grew up with 300baud modems and then 2.5Mbps Arcnet, I can’t even conceive of these speeds.

    As I listened to the interview, I was skeptical of Microsoft’s efforts. The hosts were as well, as they pressed Microsoft to really give them a reason why all this AI investment makes sense. The interview is long (1:27:47), but includes some interesting statements.

    Satya says that AI might be the biggest think since the industrial revolution. I could see that, and I’m not sure I disagree. AI tech, with the ability to reduce the requirements to interact with a computer for everyone, is incredible. It can dramatically reduce the UX issues we constantly see with developers building things that don’t always make sense to users. For me, I love that it can handle my misspellings, something many traditionally coded systems cannot handle.

    There’s also a great quote that Satya uses from a CMU professor: AI is a guardian angel or a cognitive amplifier. I think it’s both, as AI is a tool and it’s something you can use well or not. If all you have is a hammer, everything looks like a nail; that’s a famous quote. A hammer is a great tool.

    Sometimes.

    Sometimes it’s not the tool, and something else is needed. AI can be a great cognitive amplifier, but if you treat all problems as nails, you will let AI create a lot of problems. However, if you use it for the appropriate task, it can really help you. The AI can also see or spot things that we can miss as humans. As the world gets more complex, we deal with more things at once, or the rate of information coming to us increases, we may (will) miss things. An AI can do a better job of catching things, just like another person might catch things you miss.

    The last interesting thing is on models vs scaffolding where we look at what models mean and what scaffolding or infrastructure. The example is with Excel (which Satya wish had a database), but it’s an interesting look at how we might get value from AI in getting tasks done, and saving labor with AI technology. It’s worth the listen (or read the transcript).

    I found myself seeing how this might not only benefit Microsoft, but perhaps will benefit the world as other companies embrace multiple models and facilitate the ability of more people to use AI tech. I still don’t know if the ROI and costs make sense, but we will as the AI bubble bursts and this becomes a normal part of our lives in some way.

    Steve Jones

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

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

  • Your Security Checkup

    Recently I saw an article on Simple Talk, 15 Practical Tips for Securing SQL Server, and I thought that many of these are fairly simple things. Turn off unused features, disable sa, etc. These are things that a lot of people probably ensure are in their SQL Servers builds.

    Though, I’m sure a lot of people don’t bother.

    Often, I’ve found that different people might be responsible for setting up servers, or they might have rights to change things on existing servers. Over time, what we thought of as a standard often isn’t standard on all instances. Exceptions creep in, perhaps because developers change things when they don’t know better or aren’t thinking of security. Vendor software might have some  unexpected requirements for similar reasons that deviate from our standard. We also might change our own standards over time and forget to revisit existing servers.

    I wonder how many of you have a security audit procedure in place to re-examine your existing servers. It’s something that ought to be done periodically, like storage management. It isn’t needed every day or week, but a few times a year you might want to ensure things are set appropriately and ready for the next few months.

    I’ve been surprised at the number of people that really like the Redgate Monitor Configuration page to keep track of their servers and the deviations their own standard config. It’s also been interesting how many people upgrade to the Enterprise Edition to get the Security features. Tracking these over time can be a pain DBAs want an easy way to do this. In fact, there are so many feature requests for enhancements to security tracking that the devs on RGMEE are very busy.

    It’s getting to be the end of the year, and that’s a slower time for many of us. Unless your business is related to the holidays, a lot of people take vacation, we have code freezes, and there’s a little more time for housekeeping. This might be a good time to conduct a little security audit and ensure that your servers aren’t open for attack or making it easy for malicious actors, or naïve but well-intentioned coworkers, to get into systems.

    DBATools is a great way to do some changing or enforcing of standards across lots of servers. Even if you can’t change all the settings, you might ensure you have documentation on why that one instance has an sa account enabled. You might also ensure that your security people have signed off on any exceptions.

    If nothing else, a good security checkup should include checking your versions and getting up to date on patches.

    Steve Jones

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

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

  • How Important Are Real Time Decisions?

    Imagine a perfect world? I have an AI agent that knows my business well. It’s getting real time input from sales, from customers, it makes amazing decisions. We get a large order? We need to ramp up production of our widgets. We have an order pipeline of xx widgets and we know over time that yy% will close. Let’s place a larger order with a supplier overseas.

    The next day, we have an election and tariffs are announced on imported parts. We react immediately, cancel the order, start the process to expand a local factory. We place ads to hire workers and order equipment. Things are looking good for our business and our factory will be up and running in a few months.

    The next week we find out the tariffs weren’t really being enforced, so they’re paused. Our AI agent re-places our large order for imported parts and tried to cancel the factory expansion. Of course, it calculates the costs of both sides before deciding, and perhaps consults with me on other uses of our local factory.

    How many times can we do this? Or rather, how many times would we let an AI agent keep adjusting our business?

    To be fair, humans might do the same thing and over-react, but mostly we become hesitant with unexpected news. That slowness can be an asset. We often need time to think and come to a decision. Lots of our decisions aren’t always based on hard facts, and a lot of business isn’t necessarily fact driven either. We often put our thumb on the scales when making decisions because there isn’t a clear path based on just data.

    Things can get worse when we collaborate. I used to run real-time reports for an importing company, and we found that executives would print a report, get busy, and after minutes (or hours), discuss the report with someone in a department. However, their numbers rarely matched because the reports were printed at different times. At first they lost trust in the system because the same report on the same day had different numbers. Even when we added a “print” or an “as of” time, the reports were too annoying to users to be helpful because the numbers didn’t match.

    Real time isn’t what most of us want. Except in the Olympics. There we want the photo finish right away.

    But not in all sports. A review is good. In the NFL, I’ve come to like instant reply. It’s gotten better/faster and often gives us the right answer. Not always, but often. It’s better, arguably, then just real-time humans.

    Real-time decisions and reactions can be good in some cases. Adjusting machinery, vehicles, electricity, etc. where we need too-quick-for-humans decisions based on data is a good place for real time data. Lots of business decisions we make aren’t the places where we really need real-time insights. Our human brains just don’t work that fast.

    Steve Jones

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

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