Daily Coping 9 Sep 2022

Today’s coping tip is to let go of self-criticism and speak to yourself kindly.

This tip follows on nicely from yesterday’s tip, just the other side of that one. I wanted to criticize myself recently for not having a bit more content prepped before my vacation. I was gone for 8 days, and while I had content scheduled for the time away, and for a day after I returned, I didn’t have any beyond that, which puts me in a bit of a crunch.

My career at SQL Server Central is running the site like a newspaper, which means things scheduled out a week or two in advance. Trying to pull content together a day or two before it’s needed is hard. It is also very stressful. I returned from vacation with 2 days of things, but not 4 or more, which meant that I needed to do some editing for articles and some writing for editorials.

Some weeks editorials flow and I can write 3, 4 or more. Others I struggle to produce one. I returned from vacation with 3 days to write an editorial or two (hopefully more) and relieve the stress.

I started to chastise myself for not having 1 or 2 more prepared for the next week and then stopped. That wasn’t helpful, and instead I decided to tell myself that I’ll come up with something interesting to say and just set aside some time to start writing.

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 , , | 2 Comments

Daily Coping 8 Sep 2022

Today’s tip is to notice the things you do well, however small.

I think I have a lot of room for improvement, and it’s easy to self-criticize and find things that I ought to do better. As my wife would say, don’t should on yourself, and I try to follow this advice.

I do quite a few things well, some of which aren’t big, but they are helpful to others. I work very hard to meet deadlines, which means I also work to not overcommit myself. I practice my presentations a number of times to ensure I can deliver them smoothly and audiences enjoy the talk while learning something. I try watch for places that I can help others, both inside Redgate and in the community, looking to provide information that can clarify how some bit of technology works, and including references where possible.

I started to add a daily coping tip to the SQLServerCentral 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 , , | 2 Comments

Replacing NULLs in a Left Join–#SQLNewBlogger

I saw someone ask a question on how to replace NULL in a left join and decided to write a post. I realized this is one of those simple things that people new to SQL might not get.

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

A Left Join Example

Let’s create a table of customers and orders with a few values in each. This is common, where we have customers that we might add as prospects in some CRM type system. Then we link orders to customers.

Use this code:

DROP TABLE IF EXISTS dbo.Customer
GO
CREATE TABLE dbo.Customer
( CustomerID INT NOT NULL IDENTITY(1,1) CONSTRAINT CustomerPK PRIMARY KEY
, CustomerName VARCHAR(20)
)
GO
INSERT dbo.Customer (CustomerName)
VALUES
   ('Joe'),
   ('Bob'),
   ('Sally'),
   ('Amy')
GO
DROP TABLE IF EXISTS dbo.OrderHeader
GO
CREATE TABLE dbo.OrderHeader
( OrderID INT NOT NULL IDENTITY(1,1) CONSTRAINT OrderHeaderPK PRIMARY KEY
, CustomerID INT
, OrderNote VARCHAR(100)
)
GO
INSERT dbo.OrderHeader (CustomerID, OrderNote)
VALUES
   (1, 'Initial Order'),
   (1, 'Re-order'),
   (3, 'Initial Order')
GO

Potentially, we have customers without orders. If we use an inner join, we only see customers with orders. Using the left join below, we see all customers with their corresponding orders.

SELECT
   c.CustomerID
, c.CustomerName
, oh.OrderID
, oh.OrderNote
FROM
   dbo.Customer AS c
   LEFT JOIN dbo.OrderHeader AS oh
     ON oh.CustomerID = c.CustomerID;
GO

I see these results:

2022-09-02 14_00_08-SQLQuery6.sql - ARISTOTLE.sandbox (ARISTOTLE_Steve (58))_ - Microsoft SQL Server

This works, but really, I’d like to clean up the results to show something better.

Looking for NULLs

I can use a couple of functions to look for a NULL value in my results. Both ISNULL and COALESCE can help here. ISNULL is for a single expression and replaces NULL with value, while COALESCE works by returning the first non-NULL expression. I’ll use ISNULL here and in another post look at COALESCE.

Here’s a better query that replaces one value with a NA and another with a blank.

SELECT
   c.CustomerID
, c.CustomerName
, ISNULL(oh.OrderID, 0) AS OrderID
, ISNULL(oh.OrderNote, 'No orders placed') AS OrderNote
FROM
   dbo.Customer AS c
   LEFT JOIN dbo.OrderHeader AS oh
     ON oh.CustomerID = c.CustomerID;
GO

Here are the results. Note that I return a 0 for the OrderID. This is because the result set is a numeric, and I need these types to match.

2022-09-02 14_04_37-SQLQuery6.sql - ARISTOTLE.sandbox (ARISTOTLE_Steve (58))_ - Microsoft SQL Server

I could also return a string if I cast all OrderIDs to strings, as shown below.

SELECT
   c.CustomerID
, c.CustomerName
, ISNULL(CAST(oh.OrderID AS VARCHAR(20)), 'N/A') AS OrderID
, ISNULL(oh.OrderNote, 'No orders placed') AS OrderNote
FROM
   dbo.Customer AS c
   LEFT JOIN dbo.OrderHeader AS oh
     ON oh.CustomerID = c.CustomerID;
GO

This produces these results.

2022-09-02 14_05_29-SQLQuery6.sql - ARISTOTLE.sandbox (ARISTOTLE_Steve (58))_ - Microsoft SQL Server

Both cases clean up the NULL values with something that makes more sense to a person looking at the data in a report.

SQLNewBlogger

This was a post inspired by a question I saw. This is how I’d solve the issue, and decided to share that knowledge more widely, both to help others and also provide an example of where I might have a hiring manager ask me about this from noticing my blog.

This post took about 15 minutes to write. You could easily do this on your blog.

Posted in Blog | Tagged , | Comments Off on Replacing NULLs in a Left Join–#SQLNewBlogger

Developer Optimism

Developers, in general, are very optimistic about the code they write. This is likely one cause of their estimates of the time required being low, as well as the various bugs that slip through because of corner cases that appear for the problem being solved. Often developers think they’ve considered the various ways this code ought to work and covered all the possibilities. Usually we find they’ve not thought about the problem from other perspectives and need to adjust their code.

They often also feel that their code is superior to others, and that they can examine a problem in a new way. One of the reasons that I think many developers want to rewrite systems in some new technology or new way, embracing the Not-Invented-Here way of looking at other people’s code. They want to write their own solution.

Of course, many developers these days don’t eschew all code from others. Usually, it’s just other people in their organization, as a developer will embrace some random open source project they’ve discovered, sure that using this library/language/whatever will make their code better. While I do think there are examples of some new tech that is better than what’s around, I don’t know that any of them are a panacea. While F# is praised in many circles as better than C#, it’s not widely used, at least according to surveys of the top programming languages in use (IEEE, SO). It must not be better enough to get more projects to use it.

What is widely used is SQL. In fact, if we look t0 other database languages, nothing else is close. While I’m sure plenty of those C# and Java programmers use LINQ or some ORM to produce the SQL code, I don’t know many competent or highly regarded developers that can’t write some SQL code or don’t regularly write SQL.

There are some interesting ruminations on the optimism of developers in this piece. It made me smile, and I like the practical ending. While you can debate and discuss things, ultimately we need to ship code. And we are almost always better off using a technology we know rather than searching for a perfect new one to solve our problems.

When working with databases, relational or even most of the popular NoSQL ones, this means knowing SQL. And when trying to solve our database problems, in many cases, this means learning to better write SQL and build relational entities, not abandoning our platform for some new shiny one that we think will make everything run smoother.

Steve Jones

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

Posted in Editorial | Tagged | 2 Comments