On the future of user preferences #675
stwalkerster
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
There's a few issues (#674, #670, #594) at the moment which talk about adding user preferences for various things.
Continually adding user preferences makes the user table quite wide, and relies on us changing the database schema for every single user preference we want to add. This is not something I'm strictly opposed to, but it does make the process of adding new user preferences harder.
Currently, the table looks like this:
My proposal is that we split out all user preferences that don't matter for indexing/ACL into another table, keyed on
(user id, preference name)
, thus converting the problem of user preferences into a data problem, not a schema problem. The proposed table structure would look something like this:In theory, this makes retrieving specific preferences require another database round-trip, but also has leaner responses to preference requests, as well as the aforementioned benefit of no schema changes for preferences.
Opinions?
Beta Was this translation helpful? Give feedback.
All reactions