I am working on a project with the following data structure :


A user need to be able to perform personal filtering on a given project, and this filtering needs to be saved (for each user/project pair). For example, he can choose to filter based on attribute1, attribute 2.

For storing such user settings, I did use this schema:

enter image description here

and I can have for example a setting for attribute1 filtering, and in my user_setting table store the corresponding value.

My problem is that the user needs to be able to perform a manual filtering on the objects (i.e. filtering them with checkbox). That would result in choosing objectIDs among all the object IDs.

My first thought was to store them in setting_value as comma separated values, but I read that I should not denormalize (note that there can be a lot of objects, and a lot of projects).

Is it a good approach or should I rethink my user setting storage approach?

1 Answer 1


Since you need to use the IDs of manually selected objects to query those objects, it would be counter-productive to store them as a single column value. I would probably choose to store the manually selected object IDs in their own table.

  • Good point about the fact that I will need to query the IDs, so my table would be something like |id|project_id|user_id|selected_object_id| resulting in one row for each selected ID, that would result in a very large table since there could be a lot of users/project combinations, is that a problem regarding any performance issues ?
    – cicero
    Commented Jul 29, 2021 at 14:52
  • 1
    Performance concerns can only be answered by simulation testing. "very large table" is a subjective measure.
    – mustaccio
    Commented Jul 29, 2021 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.