Sql query - getting rid of hard-coded values - sql

Question

I have the following query:
Select Name,
case when charindex('I',a.S_Data) > 0 then 1 else 0 end as Illustrated,
case when charindex('FP',a.S_Data) > 0 then 1 else 0 end as FrontPage,
case when charindex('BP',a.S_Data) > 0 then 1 else 0 end as BackPage,
case when charindex('ELP',a.S_Data) > 0 then 1 else 0 end as EDLP,
case when charindex('PR',a.S_Data) > 0 then 1 else 0 end as SpecialPromo
From Table1
What I would like to do is to store those filter values in some sort of lookup table or a settings table.
I am struggling with how to draw the values from a lookup table to use with this query.

Answer 1

I can think of at least two options...
CREATE TABLE constants (
id AS INT,
Illustrated AS VARCHAR(3),
FrontPage AS VARCHAR(3),
BackPage AS VARCHAR(3),
EDLP AS VARCHAR(3),
SpecialPromo AS VARCHAR(3)
)
INSERT INTO constants SELECT 1, 'I', 'FP', 'BP', 'ELP', 'PR'
SELECT
Name,
CASE WHEN CHARINDEX(constants.Illustrated, data.S_Data) > 0 THEN 1 ELSE 0 END AS Illustrated,
etc, etc
FROM
data
INNER JOIN
constants
ON constants.id = 1
Or...
CREATE TABLE constants (
constant_set_id AS INT,
constant_name AS VARCHAR(16),
value AS AS VARCHAR(3)
)
INSERT INTO constants SELECT 1, 'Illustrated', 'I'
INSERT INTO constants SELECT 1, 'FrontPage', 'FP'
INSERT INTO constants SELECT 1, 'BackPage', 'BP'
INSERT INTO constants SELECT 1, 'EDLP', 'ELP'
INSERT INTO constants SELECT 1, 'SpecialPromo', 'PR'
SELECT
Name,
MAX(CASE WHEN constants.constant_name = 'Illustrated' AND CHARINDEX(constants.value, data.S_Data) > 0 THEN 1 ELSE 0 END) AS Illustrated,
etc, etc
FROM
data
INNER JOIN
constants
ON constants.constant_set_id = 1
GROUP BY
data.name
Both let you have multiple different sets of constants. One is expandable without changing the schema, though the query still would need to change.
The main advantage of either approach is that you can re-use the constants else where, but store them once in a centralised location. Which is only relevant if/when the values in the constants needs updating. Re-use through indirection.

Answer 2

At the moment, your table apparently violates First Normal Form, since a single field can hold many values for a single record.
There are at least two ways this could be resolved:
(1) if the only values that can be stored in this field are the five specified in the query, it might make sense to replace the character field with five integer fields, each a flag for the specified condition - ie:
...
Illustrated int,
FrontPage int,
BackPage int,
EDLP int,
SpecialPromo int,
...
(2) If a variety of different conditions are to be stored, then I would suggest adding a lookup table for conditions, and a link table between the conditions and the original table - like so:
Conditions
----------
Condition_id
Description
Link_Table
----------
Table1_id
Condition_id

Answer 3

First, it would appear that Table1 is not first normal form (NFNF) because it violates the requirement that each tuple of has exactly one value for each attribute being of the type that is the declared type of that attribute i.e. the S_Data has multiple scalar types. You will suffer update anomalies e.g. deleting a setting presumably involves an UPDATE with text concatenation. Consider that SQL doesn't has operators that handle this kind of data (i.e. non-relational) very well.
Second, your output table is suboptimal becasue it returns the same type as multiple columns i.e. it looks more like a report.
Consider that the unit of work in SQL is the row:
CREATE TABLE Settings
(
Setting VARCHAR(15) NOT NULL UNIQUE
);
INSERT INTO Settings VALUES ('Illustrated'), ('FrontPage'), ('BackPage'),
('EDLP'), ('SpecialPromo');
CREATE TABLE Table1
(
Name VARCHAR(20) NOT NULL,
Setting VARCHAR(15) NOT NULL
REFERENCES Settings (Setting)
ON DELETE CASCADE
ON UPDATE CASCADE,
UNIQUE (Name, Setting)
);