Daily Coping 14 Sep 2022

Posted on September 14, 2022 by way0utwest

Today’s coping tip is to give yourself permission to say ‘no’.

This is my default, and it was something I consciously made a decision to do over a decade ago. In general, my instinct is to say no to new requests from others. Then if I have time, I can always change my mind if it’s important or I can fit it into my schedule.

I’m not so good at this in my personal life. My wife asks me, or I want to do something, I tend to say “yes” to myself. Especially if it’s a physical project that I can (or have) handle.

However, I do get myself overloaded at the ranch. I’ve started to try and remind myself to say “no” to some projects. Either they get delayed or we pay someone else to do them. I had some lawn work to do recently and I told myself “No” and asked a kid to tackle it.

Both a chance for me to say no and ask for help.

I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 14 Sep 2022

T-SQL Tuesday #154–Thinking about SQL Server 2022

Posted on September 13, 2022 by way0utwest

This month is an interesting T-SQL Tuesday party, as Glenn Berry hosts and asks us to think about the upcoming new release of SQL Server. Sometime later this year, I expect SQL Server 2022 to be released and Glenn is asking us to talk about our experiences.

If you haven’t looked at this new version, which is in RC0, you might take a few minutes to play with it and see if the language (or other) changes might be useful in your organization.

If you want to host a T-SQL Tuesday yourself, ping me on Twitter.

My Work with SQL Server 2022

I first saw some demos of SQL Server 2022 in 2021, at various conferences. Microsoft showed off some new capabilities, some of which were very interesting. I was lucky as an MVP to get some access to private, pre-CTP builds and experiment a bit with new features.

This spring Microsoft publicly released CTP 2.0, then 2.1, and now RC0. I’ve upgraded to 2.1 on my desktop, and was waiting the docker container to update before moving to RC0. just after Glenn’s invitation, I saw the container was up to date, so I pulled a new one.

I’ve run some of my old demos on the platform, just to check that they work. That’s really work to see if there are any regression bugs. I have rarely found this to be the case, but it has been interesting to do this with 2017, with the linux version, and more. I’ve only been lightly interested in this release, as a few of the changes aren’t applicable for the work I do with Redgate. Others might be interesting to the community, and I need to spend more time on them.

Really, I got mostly interested in the T-SQL language changes. I had been using Window functions and the OVER() clause quite a bit and find writing them cumbersome, but I was excited to see the SELECT..WINDOW clause. I’d also liked the STRING_SPLIT enhancements with an ordinal.

There was an article sent to SQL Server Central that got me to look at more of the features, and I think that while most of these aren’t changes I’ve been needing, they do improve and round out the language. I look forward to experimenting with them a bit.

I’ve reproduced a few performance demos, looking at the query optimization features, and those seem good, but for me and many other developers, these will just be things that should work. Not something to get too excited about. Unless you’re on call, then you might really want to upgrade and hope these fix some of your problems without creating other ones. Maybe the thing I’m most excited about is the granular UNMASK permission, which has been overdue for a couple of versions.

I don’t quite know what to think of this new version. While there are more changes than I expected, it feels like a lot of small changes and not much of a fundamental shift in the product. I suppose it’s a major release, but kind of like SQL Server 2014, this feels more evolutionary than revolutionary.

Posted in Blog | Tagged , , | 3 Comments

Daily Coping 13 Sep 2022

Posted on September 13, 2022 by way0utwest

Today’s coping tip is to focus on the basics today, eat healthy food, drink water, get exercise.

I’m trying to make all of these a lifestyle change. In January, I worked on all of these, trying to lose weight. Which I’ve written about before. I was down about 25 lbs this year, then a bunch of travel, hormone therapy, and vacation had me up around 10lbs, but I’ve gotten back down to my 22-23lbs down from Jan 1. Not quite the goal, but close.

I wrote this a few days ago, but my routine for the day was to do the following:

  • up early for work, make some black coffee, eggs, spinach, and turkey bacon
  • take a large water bottle to my desk and drink it by lunch
  • work and have a mid-morning protein smoothie
  • more water and a break at 1130 to go to the gym.
  • lunch, ground turkey in a salad with avocado
  • more water and an afternoon smoothie around 400p
  • break from work and cook dinner around 6-630p. Tonight I did chicken fajitas over cauliflower rice for me.

That’s my routine most of the time I am at home. Some variation on recipes, but the pattern is pretty close. The gym is sometimes earlier or later, but for the most part, this has worked well for me. Made coping with the transition out of the pandemic better.

Wish I’d started this earlier in 2020 or 2021.

I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 13 Sep 2022

The Challenge of Early Tech Decisions

Posted on September 12, 2022 by way0utwest

When we design software or databases, we have to make decisions right now. If you work in as many environments as I have, this means I’m often picking a tool, platform, version, technology, or something else without a complete set of information. In some cases, I’m actually writing code (SQL or C#/Java/etc.) without completely knowing the business problem I’m solving. I do know what someone described, but as many of us find out, those descriptions often prove to be lacking.

Over time, we refine the code with feedback from users, which is why DevOps has become so popular. We write the best code we can and then quickly alter code if we haven’t hit the mark. We constantly adjust by making small changes and improvements.

However, changing the code is one thing. Changing more fundamental technology choices is harder. There is an interesting post on the disproportionate impact of your early tech decisions from one of the developers at Stripe. One of the examples given is for the database platform, which was Mongo. The piece notes that once the database platform is chosen, most groups never switch platforms. I think that’s been true in many places I’ve worked. The same thing for languages and cloud providers as well, as once a choice is made, rarely does a team, much less an organization, switch.

Why is this? Is the cost of switching that high? I think it is. I’ve seen a few organizations want to migrate from a licensed relational platform to one that is free and OSS. However, the time it takes to rewrite code, the time to build new expertise, learn the tips and tricks for a new database (or other platform technology) is significant. A team can make no shortage of mistakes during this process. Is that worth the cost of licensing?  Perhaps. Perhaps not. It’s a hard thing to decide. With the high cost of labor, I think it’s hard to make a good argument to rewrite.

In many cases, I’d argue that core changes to your technology stack ought to be considered, but understanding that no tech will solve all your problems and you will make lots of mistakes in the process of changing. Does this mean you need to make a great decision when you start working on a project? In my mind, no. Make the decision to use what your team is most familiar with and then live with it.

And be open to using targeted technology for specific needs. Lots of transient data in a busy workload? Add Redis to your database stack. If you need full-text search, consider ElasticSearch. Maybe add a graph database (not SQL Server) if you need queries in this problem domain. Use what works, and learn to use it well.

That last sentence might be the most important. Any technology can likely support most workloads, but you need to write good code and learn to use the platform well.

Steve Jones

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

Posted in Editorial | Tagged | Comments Off on The Challenge of Early Tech Decisions