Database user table design, for specific scenario

I know this question has been asked and answered many times, and I've spent a decent amount of time reading through the following questions:

• Database table structure for user settin开发者_如何学Gogs
• How to handle a few dozen flags in a database
• Storing flags in a DB
• How many database table columns are too many?
• How many columns is too many columns?

The problem is that there seem to be a somewhat even distribution of supporters for a few classes of solutions:

• Stick user settings in a single table as long as it's normalized
• Split it into two tables that are 1 to 1, for example "users" and "user_settings"
• Generalize it with some sort of key-value system
• Stick setting flags in bitfield or other serialized form

So at the risk of asking a duplicate question, I'd like to describe my specific scenario, and hopefully get a more specific answer.

• Currently my site has a single user table in mysql, with around 10-15 columns(id, name, email, password...)

• I'd like to add a set of per-user settings for whether to send email alerts for different types of events (notify_if_user_follows_me, notify_if_user_messages_me, notify_when_friend_posts_new_stuff...)

• I anticipate that in the future I'd be infrequently adding one off per-user settings which are mostly 1 to 1 with users.

I'm leaning towards creating a second user_settings table and stick "non-essential" information such as email notification settings there, for the sake of keeping the main user table more readable, but is very curious to hear what expects have to say.

Seems that your dilemma is to vertically partition the user table or not. You may want to read this SO Q/A too.

i'm gonna cast my vote for adding two tables... (some sota key-value system)

it is preferable (to me) to add data instead of columns... so,

add a new table that links users to settings, then add a table for the settings...

these things: notify_if_user_follows_me, notify_if_user_messages_me, notify_when_friend_posts_new_stuff. would then become row insertions with an id, and you can reference them at any time and extend them as needed without changing the schema.