Doing Good at SQL Server Central

This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month.

We did photoshoots at Redgate many years ago. We had a bunch of props, including some phrases written down. We could create our own, but my handwriting is atrocious (likely why I never became an architect), but I ended up with this one:

Steve Jones caption "Doing Good"

I couldn’t really explain why I picked “Doing Good”, but the more I thought about it over the years, it’s been a lot of what has driven my life forward, both here at SQL Server Central and in my personal life. I’ve been a Boy Scout and Girl Scout leader, have been and am a sports coach, and I have given up no shortage of time to help others with speaking efforts. I put time into the SQL Saturday charitable foundation, trying to get more SQL Saturday and Day of Data events that teach, train, and inspire data professionals.

SQL Server Central has a huge reach. We’ve been very popular, and millions of people have seen our newsletters. Our mission early on was to help database professionals get better every day, and we provided a lot of free (as in beer) resources: articles, quizzes, and answers to your questions. Many community members have also volunteered their time and expertise to help, and I thank them as well.

There have been a few times when I’ve tried to use that reach to do good. I don’t want to point out the specifics, but a few times I’ve known people with very sick children. One was a local friend I’d worked with (tech pro, but not database) and another was a speaker in our community. This started when I was sitting at dinner with a fellow speaker, who was talking about this family struggling and needing help. I thought, surely we as a community could raise money and help them. I used the reach of our newsletter at that time to ask for donations and managed to raise substantial amounts of money to help a family. I did it again a few years later, raising well over USD$10k in both cases.

In those cases, as well as with SQL Saturday, I have done what I thought was in the best interests of everyone and ensured all the monies raised went to the intended recipients. The families got all the money donated, and all sponsorship monies to to events. If there are bank charges or other fees, I absorb them. In the case of SQL Saturday, I go begging for donations to support the admin costs and fees.

Those might be some of the things I’m most proud of in my life, which is an interesting thing I learned. I really like helping others. As much as I enjoy living my life, I get more satisfaction that I would have expected by helping others grow, learn, succeed, and enjoy their own lives.

I think everyone should volunteer some of their time/resources/knowledge/etc. at some point in their life. It might not be now, but think about where you can help make the world better. You’ll gain way more than you ever spend from helping others..

Steve Jones

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

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

Posted in Editorial | Tagged | Leave a comment

Advice I Like: In 100 Years

In 100 years a lot of what we take to be true now will be proved to be wrong, maybe even embarrassingly wrong. A good question to ask yourself today is “what might I be wrong about?” – from Excellent Advice for Living

In this age of AI, which is an incredible disruptor, it’s interesting to think back about past changes. I heard someone recently compare the AI revolution to the change from assembler to C (high level languages). That’s interesting, but I think it might be even more impactful.

And I’m a little worried.

In any case, 100 years ago we were in the boom of the stock market, the roaring 20s. The teletype was in use, people thought after WWI that life would be amazing and we’d never go to war like that again.

I can’t imagine 100 years, but I have been skeptical of AI, especially writing good code. At this point, after more testing, I think I was wrong about AI being a disruptor for tech. With advances in robotics, I truly worry that AI might cause serious challenges for humanity.

I hope I’m wrong.

In terms of databases, I constantly think relational systems are the best all-around store and a good choice for most work. I constantly ask myself if I could be wrong. I don’t think I am, but I keep asking the question.

It’s good to ask yourself this type of question. Have those strong opinions, but loosely held.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

Posted in Blog | Tagged , | Leave a comment

Engineer Lessons

Many of you reading this have a number of years working with technology. You might have 1 year or 20 years, but you’ve likely grown and learned along the way. Some of you may also know someone who has several years of seniority in a position but not that many years of experience. In this case, a person might have been working at this job for 5 years, but they really have one year of experience that’s been repeated 5 times.

That’s been a common complaint over quite a few years from people who interview others. They find candidates often have very limited experience, yet are applying for senior roles. These candidates are ones who have just a few years of experience, but have ended up repeating those few years over and over.

I ran across an interesting piece that contains 21 lessons from the author’s 14 years at Google. You might not think Google is the place where great software engineering takes place, or where great careers are made, but Google has been a place where it is challenging to get a job, they work on truly large-scale problems, and Google has had many engineers who have gone on to success elsewhere.

The first few lessons in here are things that I’ve learned in my career. Quite a few of them point to the value of being a team player, and remembering that being effective and efficient matter. It’s easy to be smart, or depend on one’s code to speak for our ability, but in many cases, we are working in teams. Our code is a team game, and others need to understand our code. It’s easy to forget that someone responding to a problem at 2 am might not understand the code. It’s also easy to forget that person might be you, and you might get confused.

Others also need to understand and believe in us. Lessons 2, 14, and 16 talk about the value of working with others and not creating resentment or ill will in others. Even with AI help, most software will require multiple people working together, so building those skills and habits is important.

I found this to be an interesting list, and there are other topics I want to discuss in the future, but the main thing I see here is that these are lessons from someone who has had to work as a technical engineer with others, while having success both at his job and outside of it. That resonates with me, as do these lessons. Individuals and teams that work in similar ways to those described in the piece have tended to have more success than those that don’t, at least in my experience.

Learn to be a team player as an engineer, developer. DBA, or any other job, and you will have more success than if you expect to only be judged on what code you write.

Steve Jones

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

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

Posted in Editorial | Tagged | Leave a comment

RANK() vs DENSE_RANK(): #SQLNewBlogger

I haven’t done one of these in awhile, but I saw an article recently about this and decided to explain it to myself, but in a slightly different way. You’ll see how I checked on RANK() vs DENSE_RANK() below.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Getting Started

Imagine you’ve never used these functions, but you need to rank some data. Let’s say that you have a series of things that measure sale and you want to know who has done the best job this week. I’ll start with AdventureWorks, and we’ll assume it’s June 2011. If I look at some data from that database, I see this. Order Headers and Order Details from that range.

2026-02_0125

Who are the top 5 salespeople?

I put this into SQL Prompt AI: who are the top 5 salespeople with ranking for the first week of june 2011. Give me the salespersonid, the rank and sales total

I got this code, though with 2011-06-01 as the first date, which didn’t work as there were no orders that week. I adjusted this back to May 31. You can see this uses RANK() as the aggregate.

2026-02_0126

I then asked about DENSE_RANK, because I heard about it and might want to use it.

2026-02_0127

Prompt adjusted the query to add DENSE_RANK, but I then clicked the “add explanation” next prompt prompt (is that a thing now?)

2026-02_0128

I now see an explanation, though in this example, this doesn’t help.

2026-02_0129

I then asked Prompt to help me understand.

2026-02_0130

I got back this code. You can see in the results, that both show me the ties for 2nd with people that have the same sales totals. However, with RANK, we jump to 5, since there are 3 people tied at 2 (presumbly taking 2,3,4th place). The dense ranking goes from the ties at 2 to 3.

2026-02_0131

I asked for an explanation:

2026-02_0132

I got this. This is the text from SQL Prompt AI (in italics):

# RANK vs DENSE_RANK: When to Use Each


The key difference between RANK and DENSE_RANK is how they handle ties:


## RANK
– Assigns the same rank to ties
– Skips the next rank(s) after ties
– Creates “gaps” in the ranking sequence
– Example: 1, 2, 2, 4, 5 (note the missing 3)


## DENSE_RANK
– Also assigns the same rank to ties
– Does NOT skip ranks after ties
– Creates a “dense” or consecutive ranking without gaps
– Example: 1, 2, 2, 3, 4 (no gaps)


## When to use DENSE_RANK:
1. **Consecutive Ranking Systems**: When you need a continuous sequence without gaps, such as in competitions where tied participants should receive the same position, but the next participant should be ranked immediately after.


2. **Top N Analysis**: When identifying items in the “top 10” or similar groups, DENSE_RANK ensures you get exactly 10 distinct ranks regardless of ties.


3. **Percentile Calculations**: When calculating percentiles or quartiles where a continuous ranking is needed.


4. **Educational Grading**: When multiple students with the same score should receive the same rank, but the next student should be ranked immediately after.


## When to use RANK:
1. **Traditional Competition Standings**: Olympic medals and many sports competitions use this approach – if two athletes tie for first place, the next finisher gets bronze (3rd place, not 2nd).


2. **Statistical Analysis**: When you need to preserve the mathematical properties of ranks where the sum of all ranks should equal the sum of consecutive integers.


3. **Scenario Where “Skipped” Positions Matter**: When it’s important to account for how many entities are ahead of each entity.


Your example query perfectly demonstrates this difference:
– Employees with $145,000 all get rank 2 with DENSE_RANK
– With RANK, they get position 2, but the next rank is 5 (skipping 3 and 4) because there are three employees sharing rank 2


Each function has its appropriate use cases depending on whether you want a continuous ranking sequence or one that accounts for the number of entities at each rank level.

What I Learned Here

I knew most of this, but in terms of trying to understand better where/why to use each, the explanation made sense. I hadn’t thought about the Educational Grading for DENSE_RANK, but that makes sense. I knew the others, and often that the TOP N needs the correct number of rankings.

For RANK, we use the competition ranking with volleyball, so I see that all the time, but I don’t do a lot of statistical analysis where this has come up, but it’s good to keep it in mind.

To me, I often go back to the client, or think about both of these when I rank things. I will do what Prompt AI did and put both in a query, see the differences and then decide (or let someone else decide) how to present the ranking data.

SQL New Blogger

When I started to explain this, I first opened the DOC pages and was going to use those to write this and thought, this is a good place to test AI models and see. I took a different tact and incorporated some AI into my work, because that’s where the world is going. Like it or not.

This went faster with AI, and less cognitive load from me. I wrote this post, but I used AI to help set things up, generate code, and get me there quicker. You could do the same thing and use a blog to showcase that you’re learning how AI is a tool you can use.

SQL Prompt can help you learn more about your code, in addition to all the cool time saving features. Give it a try today.

FWIW, I asked CoPilot the same query and got an answer (0 people), without code. When I asked for code, I did get it, but not quite what I wanted.

Posted in Blog | Tagged , , , | Leave a comment