I've seen a few questions on here about storing user preferences, but they seem to be referring mostly to a fairly minimal set of preferences. I'm currently working on a highly customizable web app, which will need to store a great number of preferences, and I'm struggling with how to store them.
The kind of preferences I'll be storing include booleans for displaying specific tooltips, arrangement of various content panels on a page, which page to display after login, default values for specific form fields, etc. All-in-all, I'm expecting there will be 50+ preferences of this type for each user, the data being mostly booleans and integers.
I'm not a big fan of serialization, but I'm concerned about the scalability of storing each preference as an individual row. Thoughts?
Best Answer
Serializing a blob of data is the way to go here, but not for performance reasons -- rather because this is an aspect of the system that is likely to see huge numbers of changes. You don't want to have to change your DB schema just because you now need to allow a preference to turn on advanced mode on some page or something.
The entity-attribute-value model that HLGEM mentions fits this from an "easy to evolve" perspective, but as she says it would have very poor performance.
What you would give up with serialized objects would be the ability to directly query the db for users matching a certain pattern (perhaps you're tracking down a bug that would occur only with some combination of settings and you want to see if you have any users who have that combination).