We have a well designed and normalized DB, but, there is a requisit that could cloud this design.
This image shows the design of part of the DB.
The main functionality of our application is to create some stats of the quantity of notifications each user recieves. So we query the DB by groups of users (e.g.
SELECT COUNT(*) FROM Notifications INNER JOIN Users ON User.UserID = Notifications.UserID WHERE User.att = ...).
The requisit that is causing me troubles is that our application allows a user (which is different of any user stored in the table
Users, since this is a monitoring application) to customize some configuration parameters, such as miliseconds to wait before looking again in the DB in order to obtain some data for charts, which number of notifications makes a user selectable (e.g. if the user has more than X notifications then it should be displayed in the chart) etc.
This configuration must be persistant, we do not want to make the user set the parameters each time he opens the application.
The problem I see is, how do I make the configuration persistant without clouding the design. Because, if you set, lets say, the X number of notifications needed, you could see that as an attribute of
Notifications, but is kind of an Entity attribute. Since, is (conceptually) an attribute of
Notifications but what we store there are notifications, which are oblivious of configuration attributes.
Moreover, we have more entities, with exactly the same problem. An entity that stores certain kind of data, and from the application you can configure in which ways this data is going to be treated. And that configuration must be persistant.
Therefore, my question is, what is the appropiate way to represent this configuration persistance? Should it be represented in the DB or in other file? I think that it should be stored in the DB, but maybe I am being stubborn...