Database table design: How to use multiple tables to separate related data so that querying resultset is simpler or require less code? - sql

Question

I have a three tables as illustrated in the screenshots below:
The primary design objective is to separate the values in the LICENSE_REQ table: TAX, INSURANCE and BENEFIT columns from their description in the LICENSE_REQ_DESC table.
The below query returns the TAX, INSURANCE and BENEFIT columns next to their description from the LICENSE_REQ_DESC table.
Query:
SELECT A.LICENSE_ID,
B.TAX, T.REQ_CODE_DESC,
B.INSURANCE,
I.REQ_CODE_DESC,
B.BENEFIT,
J.REQ_CODE_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID
LEFT OUTER JOIN LICENSE_REQ_DESC T ON B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON B.BENEFIT = J.REQ_CODE
Tables:
BUSINESS - Primary Key LICENSE_ID
LICENSE_REQ - Foreign Key LICENSE_ID
LICENSE_REQ_DESC - Primary Key SEQ_NBR
And here is the resultset screenshot:
Is there a more effective and efficient method for separating data from meta data (description) for efficiently querying the desire resultset?

Answer 1

I like your way.
Some developers might create a stored function like get_desc(req_code) and write the SQL as:
SELECT A.LICENSE_ID,
B.TAX,
get_desc(B.TAX) TAX_DESC,
B.INSURANCE,
get_desc(B.INSURANCE) INSURANCE_DESC,
B.BENEFIT,
get_desc(B.BENEFIT) BENEFIT_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID
But I much prefer the way you've got it. Keep it all in pure-SQL when you can!

Answer 2

There are pro's and con's to the single lookup table method.
The primary pro is that all the translations are in one place, you don't need to go searching hither and yon to find each translation.
The cons are that you end up with larger lookup tables and usually more complex join requirements since there is usually a discriminator column included in the join, and you are limited to having the exact same attributes available for every lookup.
Right now your scheme doesn't include a discriminator column to determine from the contents of LICENSE_REQ_DESC which code value source the description goes with. This can be a problem if for some reason their are REQ_CODE values conflicts between the TAX, INSURANCE, and BENEFIT code columns.
An improved version of your LICENSE_REQ_DESC table would be to:
ALTER TABLE LICENSE_REQ_DESC ADD (REQ_CODE_SOURCE VARCHAR2(15) );
Populate the new column with appropriate values e.g. 'TAX', 'INSURANCE', and 'BENEFIT' then:
ALTER TABLE CODE_LOOKUP MODIFY (REQ_CODE_SOURCE NOT NULL);
ALTER TABLE CODE_LOOKUP ADD CONSTRAINT CODE_LOOKUP_UK UNIQUE
(
REQ_CODE_SOURCE
, REQ_CODE
)
ENABLE;
And finally change your query to use the following joins:
LEFT OUTER JOIN LICENSE_REQ_DESC T ON T.REQ_CODE_SOURCE = 'TAX' AND B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON T.REQ_CODE_SOURCE = 'INSURANCE' AND B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON T.REQ_CODE_SOURCE = 'BENEFIT' AND B.BENEFIT = J.REQ_CODE

Answer 3

There is some interesting reading here (in the negative):
https://www.simple-talk.com/sql/t-sql-programming/look-up-tables-in-sql-/ (although not everyone agrees with Joe Celko he always goes into depth)
Something to consider is your foreign keys. You can enforce a foreign key to this table but you cannot enforce that a tax transaction record may only use a tax description record.
Foreign keys enforce logic and can assist in generating an efficient query plan. When you are creating foreign keys that don't quite tell the whole story, it appears to indicate a design issue.
Looking ahead: Could this lookup table end up being extended to store many other types of descriptions? Could the distribution of description types be heavily skewed in some way? When you have a table whose purpose (and therefore content and cardinality) drifts over time , it can cause 'random performance issues' when statistics get stale.