Consider some code like
x
SELECT
CASE
WHEN [DECISION-MAKER] = 'COKE' THEN 'GIVE COKE'
WHEN [DECISION-MAKER] IN ('PEPSI', 'BLOOD') THEN 'GIVE DEATH'
END AS [EMPLOYEE-ASSIGNMENT],
CASE [DECISION-MAKER]
WHEN 'COKE' THEN 'Employee prefers coke. Give coke.'
WHEN 'PEPSI' THEN 'Employee prefers pepsi. Give death.'
WHEN 'BLOOD' THEN 'Employee is some sort of vampire. Give death.'
END AS [ASSIGNMENT-REASON]
FROM
(
SELECT *,
CASE
WHEN [COMPLEX-LOGIC-1] THEN 'COKE'
WHEN [COMPLEX-LOGIC-2] THEN 'PEPSI'
WHEN [COMPLEX-LOGIC-3] THEN 'BLOOD'
END AS [DECISION-MAKER]
FROM [WHEREVER]
)
I believe that the technical term for such poor code is “stringly typed”. The key issue in the above code is that decisions are being made based on a string output that the developer needs to type and consistently get correct. If anything goes wrong, the language will be incapable of throwing errors. In a traditional language, the workaround would be to construct some sort of dictionary to handle these cases. What is the idiomatic solution in T-SQL? I don’t like the idea of making a use-once table, but maybe a temp table would be helpful?
Advertisement
Answer
I wouldn’t worry about having a “Use in one place” table. If you still worry about it cluttering up your database, you can use a table variable.
DECLARE @AssignmentAndReason AS TABLE (
DECISION-MAKER varchar,
EMPLOYEE-ASSIGNMENT varchar,
ASSIGNMENT-REASON varchar
);
INSERT INTO @AssignmentAndReason VALUES
('COKE', 'GIVE COKE', 'Employee prefers coke. Give coke.'),
('PEPSI', 'GIVE DEATH', 'Employee prefers pepsi. Give death.'),
('BLOOD', 'GIVE DEATH', 'Employee is some sort of vampire. Give death.');
SELECT [EMPLOYEE-ASSIGNMENT], [ASSIGNMENT-REASON],
FROM [WHEREVER]
JOIN @AssignmentAndReason ON [DECISION-MAKER] = CASE
WHEN [COMPLEX-LOGIC-1] THEN 'COKE'
WHEN [COMPLEX-LOGIC-2] THEN 'PEPSI'
WHEN [COMPLEX-LOGIC-3] THEN 'BLOOD'
END