Convert Number to Date in SQL Server with Exception in Month-End - sql

Question

I have an INT column in my table. This column stores the date in special format. I'm trying to convert that column to DATE type.
For example, we keep '2016-03-14' as 20160314.
The exception is, for the last of each month, we do not store day.
So for '2016-03-31' we store 201603 and I have to consider if the number is less than 999999 or not to find is the number represents a month-end or other days in month.
So far, I have 2 queries to achieve this task:
Query 1:
This is all mathematics formula.
declare #k int = 20160321
--declare #k int = 201603
select
IIF(#k < 999999
, EOMONTH(DATEFROMPARTS(#k /100, #k % 100, 1), 0)
, DATEFROMPARTS(#k /10000, (#k / 100) % 100, #k % 100)
)
Query 2:
This one is using string manipulation.
declare #k int = 20160321
--declare #k int = 201603
select
IIF(#k < 999999
, EOMONTH(cast(LEFT(#k, 4) + '-' + RIGHT(#k, 2) + '-01' as date), 0)
, cast(LEFT(#k, 4) + '-' + RIGHT(LEFT(#k, 6), 2) + '-' + RIGHT(#k, 2) as date )
) AS DateColumn
I need to do the conversion formulas in WHERE clause. Something like:
SELECT K, Dt, Name -- and more fields
FROM tbl
WHERE IIF(K < 999999
, EOMONTH(DATEFROMPARTS(K /100, K % 100, 1), 0)
, DATEFROMPARTS(K /10000, (K / 100) % 100, K % 100)
) < GetDate()
And performance is important
Question: Is there a better way to do this? Possibly a ways that SQL Server can use the clustered index I have on K column.

Answer 1

I would expect that Query 1 would perform better, but you'd have to test it to be sure. I have no idea what kind of performance datefromparts() and datetimefromparts() have. They're relatively new, so it wouldn't shock me if they were magically terrible for no good reason. You're comparing performance of string manipulation and type casting vs the performance of arithmetic and type casting. My guess is it's mostly a wash, but that arithmetic is probably faster.
The options that strike me for a solution performance-wise are: a) Add a datetime column to your table. b) Add a computed column to the table. If you make a PERSISTED column, you could even create an index on it. c) Create a view (an indexed view if you can jump through the requirement hoops). d) Create a new table with the datetime field and update it.
Both (a) and (d) duplicate data, so they're not as great of solutions as they first appear.
I always have found computed columns to be a little gross, but they work well enough. If you create a view, you'll have to INNER JOIN it back to use it, but in most systems JOINS are very fast.
I'd probably look at creating a persisted computed column or a view. The best solution, of course, is to not store dates as integers in the first place.
You might try this query:
SELECT CASE
WHEN #K < 999999 THEN EOMONTH(TRY_CONVERT(date, CAST(#K * 100 + 1 AS VARCHAR(10))))
ELSE TRY_CONVERT(date, CAST(#K AS VARCHAR(10)))
END AS K_Date
The reason this might work is that YYYYMMDD is one of the ISO date formats. I'd try TRY_CONVERT() before CONVERT() because the query engine can decide to evaluate all the CONVERT without looking at the CASE conditional and throw errors.