Best practice for account settings
I have a question to ask you. There are a lot of ways to implement account settings. I’ll name three here. What’s your favorite option?
On User model
In this settings type, all the settings are made available on the User model of your web application. So, for example, each setting has it’s own column on the users table. The settings can be fetched by using User.setting directly from your MVC framework.
The advantage of this is that it is easy to set up. The disadvantage is that it is non-scalable as hell. You would be ending up with 20+ columns in a users table.
Key-value pairs
This method is used by - for example - WordPress. They have a separate wp_usermeta table with the following relevant columns: user_id, meta_key, meta_value. This way, each user can have more settings than the default user stuff like password and username.
Disadvantage is that it will take more work to nicely bind all the keys as attributes to the User model. Advantage is that it is scalable.
Hash on the Model
A third option implements both. You would put one column named “settings” on the User model and fill it with a serialized text-based hash (ie. YAML) and deserialize it every time you read or save settings. The Rails plugin acts_as_configurable does this.
What’s your take on this?
That’s not 2 but 3!
I have used the key-value pairs last time I build something with a lot of settings (but used the user table for mandatory ones such as username, email). Disadvantage of the second method isn’t that big, since the functions are really simple.
the third option can be a good or a bad idea. If you want to be able to do quick scans (show me all users where X=Y) it’s bad, because you have to open and deserialize all users.
I guess in the end the answer, as always, is: It depends..
In my opinion the send option is best if you are aiming to be scalable. This is the most abstract way of doing it so you can always change or migrate later.
I just modified an acts_as_configurable Rails plugin that used to have the third way (storing everything into a text-based hash) into the second way using an extra key-value pair based column. You can find it on GitHub: http://github.com/michiels/acts_as_configurable/tree/master Credit goes to http://github.com/omghax/ for the original plugin