Question

I’m trying to design some database tables to store configuration settings about certain entities and the applications they are associated with. I can get so far but have hit a “brick wall”. I’ll show you what I mean… (do not take the following: pictures, as a literal business problem, pictures are just an easy way of explaining my problem to you).

Criteria

1. We have a catlog of pictures.
2. We have several applications that can
   consume any number of these
   pictures.
3. We want to configure how to display these pictures
   depending on the application.

Bear in mind that each application has a specific and unique way it can be configured to show pictures.

So it’s clear we need 2 tables PICTURE and APPLICATION and a junction table to show the M-M relationship, as many pictures can be in many applications – see below:

I have highlighted in red the column “CONFIG_TABLE” – I have a very strong suspicion this is bad, very, very bad. It is showing that for a paricular app this is the config table to store the settings in. See below:

So – there are very speicific app configurations to apply to pictures, depending on what app you are talking about. Now assuming the design is broken, as I believe it it is – how do I actually design the database to model this correctly? (Hope this makes sense)

Answer 1

The design is not far off from being correct. You simply don’t need the application.config_table column. Instead, each application ought to know which table pertains to its own use of pictures.

So for example in the PicManager application, you could do this:

SELECT p.*, c.*
FROM Picture_Appliation AS pa
INNER JOIN Picture AS p ON pa.pic_id = p.pic_id
LEFT OUTER JOIN Picman_Config AS c ON p.pic_id = c.pic_id
WHERE pa.app_id = 100;

And in each of the other applications, you’d code a different config table in your query.

Don’t try to make this too “automatic” or “data-driven”. Just write the code that is appropriate in each application. You can use data-driven methods for data values (e.g. app_id=100), but not code. Data is data. Code is code.

You may want to write just one reusable class that’s employed in all your applications, but that’s what subclasses are for.