Proposing an alternative model to the UserSettings with an open-ended table model.
The model would be as follows:
code: LAbel identifying the type of setting
value: :
user_id: foreign key linking the setting row to the user
// Optional:
We could also have a database table for every setting we create, so that the code can programatically pull down the list, rather than having the potential list in code.
setting_id: A foreign key linking the row to the setting.
An example image can be found in:
https://stackoverflow.com/questions/10204902/database-design-for-user-settings
By taking this model, we can also cut down the user table by refactoring columns such as preferred pronouns and nickname to this table, allowing the table to narrow for better database design. See vertical partitioning
Proposing an alternative model to the UserSettings with an open-ended table model. The model would be as follows: code: LAbel identifying the type of setting value: : user_id: foreign key linking the setting row to the user // Optional: We could also have a database table for every setting we create, so that the code can programatically pull down the list, rather than having the potential list in code.
setting_id: A foreign key linking the row to the setting. An example image can be found in: https://stackoverflow.com/questions/10204902/database-design-for-user-settings
By taking this model, we can also cut down the user table by refactoring columns such as preferred pronouns and nickname to this table, allowing the table to narrow for better database design. See vertical partitioning