1. Одна таблица с множеством колонок
Подходит для настроек, которые есть у всех пользователей в обязательном порядке (например, логин, пароль, почта).
В остальных случаях этот вариант плохой.
2. Таблицы: Пользователи, Настройки, Настройки_Пользователей. Последняя таблица включает в себя ссылки на две первые и поле Значение для настройки.
Плохо тем, что для миллиона пользователей с 50-ю настройками будет 50 миллионов записей в таблице.
3. Предыдущий вариант, только таблицы разделять по тематике. Тогда на миллион пользователей будет всего десять миллионов записей.
Эти варианты можно оптимизировать заданием настроек по умолчанию. Если записи о настройке в базе нет, применяется настройка по умолчанию. Таким образом, количество записей можно сократить.
4. Сериализация. Количество колонок/записей сокращается, но внутренняя структура становится менее прозрачной и более трудной для обработки и сортировки.
5. XML. Хранение пользовательских настроек в XML, с использованем значений по умолчанию.

Ну и наконец, самый лучший вариант — смешанный.

«Жесткие» настройки хранить в одной таблице, на каждую настройку по колонке (Аккаунт)
Разделить настройки тематически (сейчас выделены Приватность и Уведомления)
Использовать настройки по умолчанию
Использовать XML для тех настроек (вместо сериализации — имхо, лучше использовать существующие и проверенные технологии, чем городить свои), по которым не нужно выбирать списки (медленная пакетная обработка для статистики не в счет)
Записывать настройки в сессии

По каким настройкам выборки списков (напр., права доступа к альбуке), а что отн. только к конкретному пользователю