Don't use functions in a WHERE clause if you can avoid it, as they destroy "sargability".

In this case, just directly check each variable for NULL or a match, as below. ...

An AFTER UPDATE trigger on the table would capture who, at least as well as you can within SQL Server.  You can use "UPDATE(column_name)" to limit it to only processing...

If the AccountNumber must be changed, it will have to change whether it's the clustering key, and/or a PK, or not.

In that situation, you'd temporarily disable FK checking as needed...

You'd need to post the actual code that processes the cursor for us to really accurately help.

But, likely an extra FETCH is being issued.  People insist on coding multiple FETCH...

No, ID is absolutely not needed.  It's likely to hinder processing since people tend to inevitably cluster on it.

Use the AccountNumber as the clustering key and the primary key.  You...

To avoid any IF / CASE logic, I usually use this technique instead:

SIGN(Jan) + SIGN(Feb) + ...

In situations where the numbers could ever be negative, you'd need to include ABS()...

I would think so, since SQL doesn't (re)order / sort rows going into a columnstore, it loads them in the same order in which they arrive.

Thus, presumably the first 1,048,576...

Yeah, I was incorrectly thinking of column3 also matching.

I don't like having to have duplicative indexes.  I'd probably go with just:

( column2, datetime ) INCLUDE ( column3 )

Sure, that index...

I would of that the best index would be:

(Column3, Column2, DateTime)

given the WHERE condition.

Particularly if you later use the same query with:

Where tab1.Column3= 9

to query a different column.

And I'd move...

Since an IN gets converted to ... OR ... OR ..., I suppose it might make a difference, in which case you'd want to put the most common values first.

You...

Technically, if j.Grp is NULLable, I think you'd need to use:

WHERE j.Grp IS NOT NULL AND j.Code <> 'L3'

to insure the same results as the original code.

You waste space and risk ambiguity by storing dashes in a date?  Seriously?  If for some bizarre reason one insists on storing dates as char, they should be YYYYMMDD.  Unambiguous. ...

I don't really have any issue with storing cc numbers as char(16), especially since they'll need to be encrypted and end up being stored as binary anyway.  I also wouldn't...

Actually an identifier is numeric (integer) because it just makes no common sense to do otherwise.  Overly-pedantic concerns about whether it's used in math or not are actually irrelevant.  There...

Probably cleaner to check for 0 values as you INSERT the row:

INSERT INTo #a

select NULLIF(0,0),NULLIF(1,0),NULLIF(0,0),NULLIF(2,0)

union ALL

select NULLIF(0,0),NULLIF(2,0),NULLIF(0,0),NULLIF(3,0)

union ALL

select NULLIF(0,0),NULLIF(3,0),NULLIF(0,0),NULLIF(4,0)