Simplify combining multiple table variables [closed] - sql

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have the code below (obviously with some changed names). I'm trying to find a simpler or more-effective way to create the same results. Any suggestions appreciated. THIS IS FOR FUN. MINE ALREADY WORKS
DECLARE #Scenes TABLE(IncNo numeric(12,0), SceneSquad int, ScDate datetime)
INSERT INTO #Scenes
SELECT A.IncNo, SceneSquad, ScDate
FROM DATABASE as A
LEFT JOIN DATABASE as B
On A.IncNo = B.IncNo
WHERE ScDate BETWEEN '1/1/2021' AND '10/31/2021'
AND A.DivID = ''
DECLARE #Assigned TABLE(IncNo numeric(12,0), Followupsquad int, AssignmentDate
datetime)
INSERT INTO #Assigned
SELECT IncNo, Followupsquad, ASSIGNMENTDATE
FROM DATABASE AS C
LEFT JOIN DATABASE AS D
ON D.IncNo = C.CIncNo
WHERE SOMETHING = 'Y' AND DateRuled BETWEEN '1/1/2021' AND '10/31/2021'
AND D.AssignD = ''
DECLARE #Squads TABLE(Squad int, RN int)
INSERT INTO #Squads
SELECT Squad, ROW_NUMBER () OVER (ORDER BY Squad) AS E
FROM DATABASE
WHERE UnitType = '' AND DivId = '' AND SquadStatus = 'A'
ORDER BY Squad
DECLARE #MSS TABLE (SqdNo int, SOMETHING int, SOMETHINGELSE int)
DECLARE #DATE datetime, #X int, #SQ int, #M int, #S int
SET #DATE = 1/1/2021 - 10/31/2021
SET #X = 1
WHILE #X <= (SELECT MAX(RN) FROM #Squads)
BEGIN
SET #SQ = (SELECT Squad FROM #Squads WHERE RN = #X)
SET #S = (SELECT COUNT(*) FROM #Scenes WHERE SceneSquad = #SQ)
SET #M = (SELECT COUNT(*) FROM #Assigned WHERE Followupsquad = #SQ)
INSERT INTO #MSS VALUES (#SQ, #M, #S)
SET #X = #X + 1
END
SELECT SqdNo , SOMETHING , SOMETHINGELSE
FROM #MSS

Answer 1

You can use Common Table Expressions (CTEs) in place of table variables, and this can help reduce and often speed up the code, such that we can get everything down to one (large) query with no loop:
WITH Scenes As (
SELECT A.IncNo, SceneSquad, ScDate
FROM DATABASE as A
LEFT JOIN DATABASE as B
On A.IncNo = B.IncNo
WHERE ScDate BETWEEN '20210101' AND '20211031'
AND A.DivID = ''
)
, Assigned As (
SELECT IncNo, Followupsquad, ASSIGNMENTDATE
FROM DATABASE AS C
LEFT JOIN DATABASE AS D
ON D.IncNo = C.CIncNo
WHERE SOMETHING = 'Y' AND DateRuled BETWEEN '20210101' AND '20211031'
AND D.AssignD = ''
)
, Squads As (
-- Removed row_number(), since it only seemed to be used for an index later
SELECT Squad
FROM DATABASE
WHERE UnitType = '' AND DivId = '' AND SquadStatus = 'A'
-- also moved the ORDER BY to the final SELECT
)
SELECT sq.Squad As SqdNo
, (SELECT COUNT(*) FROM Scenes WHERE SceneSquad = sq.Squad) As Something
, (SELECT COUNT(*) FROM Assigned WHERE FollowupSquad = sq.Squad) As SomethingElse
FROM Squads sq
ORDER BY SqdNo
Each INSERT/SELECT for a table variable in the original question is instead now a CTE, and we then roll up the loop into correlated sub-queries (nested SELECTS).
The weakness here is it re-runs the Scenes and Assigned CTEs for each row, where the table variables effectively let the server cache those query results. The strength is the original table indexes are still available.
But that's just step one. We can improve this further to get the best of both worlds, using GROUP BY and JOINs. The trick is if we tried to use GROUP BY to get counts from both additional queries this in the same step, the row counts would be multiplied. However, we can use another CTE to force them to happen sequentially and get the right answers. If I skip past the prior CTEs to save space, it looks like this:
, SquadPlusSceneCounts As (
SELECT sq.Squad, COUNT(*) As Something
FROM Squads sq
LEFT JOIN Scenes sc ON sc.SceneSquad = sq.Squad
GROUP BY sq.Squad
)
SELECT sq.Squad As SqdNo, sq.Something, COUNT(*) As SomethingElse
FROM SquadPlusSceneCounts sq
LEFT JOIN Assigned a ON a.FollowupSquaud = sq.Squad
GROUP BY sq.Squad, sq.Something
ORDER BY sq.Squad
This will likely perform much better. The code is also simpler because we no longer need table variables or INSERT statements and I was able to remove the row_number() and loop. Finally, we preserved the intermediate logic and naming, so it will still be maintainable in a similar way (you can run most of the CTEs independently to verify them).
All of this was a straight-up translation of the code from the question. Better understanding of the data might also allow for logical improvements with further performance benefits and simpler code.
However, there's still the matter of the #Date variable; it's not at all clear what you were doing there. SET #DATE = 1/1/2021 - 10/31/2021 makes no sense, and it wasn't used later. You may need an additional CTE that generates dates based on an initial value on the fly, that you can then also JOIN to. There are a number of ways to do this, and since I don't know it's even needed I'll leave it as an exercise.
One more thing. In many cases where CTEs are used, it's possible to wrap them up into nested SELECT queries instead. I tend to avoid this, because it's harder to maintain (you lose a level of naming or mnemonics and you can't run the CTE by itself as easily for testing/maintenance), but you can sometimes get a small performance benefit this way.
So for completeness, view the monstrosity below:
SELECT sq.Squad As SqdNo, sq.Something, COUNT(*) As SomethingElse
FROM (
SELECT sq0.Squad, COUNT(*) As Something
FROM (
SELECT Squad
FROM DATABASE
WHERE UnitType = '' AND DivId = '' AND SquadStatus = 'A'
) sq0
LEFT JOIN (
SELECT A.IncNo, SceneSquad, ScDate
FROM DATABASE as A
LEFT JOIN DATABASE as B On A.IncNo = B.IncNo
WHERE ScDate BETWEEN '20210101' AND '20211031'
AND A.DivID = ''
) sc ON sc.SceneSquad = sq0.Squad
GROUP BY sq0.Squad
) sq
LEFT JOIN (
SELECT IncNo, Followupsquad, ASSIGNMENTDATE
FROM DATABASE AS C
LEFT JOIN DATABASE AS D
ON D.IncNo = C.CIncNo
WHERE SOMETHING = 'Y' AND DateRuled BETWEEN '20210101' AND '20211031'
AND D.AssignD = ''
) a ON a.FollowupSquaud = sq.Squad
GROUP BY sq.Squad, sq.Something
ORDER BY sq.Squad
But again, don't do this last part unless you have to.
As a complete aside, as bad as this is, it demonstrates why I'm not a fan or ORMs. As ugly as this code is, I don't want to think about trying to replicate it via ORM syntax. And even if you could, you'd still need to know how to write code like this in order be sure it's right... at which point you may just as well devote your time to learning good SQL.