Как лучше хранить настройки пользователей в БД?

Я в одном очень большом проекте подсмотрел классную фичу с "виртуальными столбцами", теперь очень часто пользуюсь в аналогичных, как у Вас случаях.

Таблица концептов(concept):
ID | NAME
200 | Параметры отправки почты
300 | Параметры отправки заданий
....

Таблица параметров(param):
ID | CONCEPT | NAME
1 | 200 | Отправлять в пн
2 | 200 | Отправлять во вт
3 | 200 | Отправлять в ср
...
10 | 300 | Отправлять задание 1
11 | 300 | Отправлять задание 2
12 | 300 | Отправлять задание 3
...

Таблица Пользователей(users)
ID | NAME
1 | Саша
2 | Петя
3 | Вася
...
Таблица реальных значений(xval)
ID | CONCEPT | USR_ID | PARAM_ID | VALUE | ACTUAL
1 | 200 | 1 | 1 | 1 | 1 | - Отправляем Саше по понедельникам почту
2 | 200 | 1 | 2 | 1 | 1 | - Отправляем Саше по втоникам почту
3 | 200 | 1 | 3 | 1 | 1 | - Отправляем Саше по средам почту
4 | 200 | 2 | 3 | 1 | 1 | - Отправляем Пете по средам почту
5 | 200 | 3 | 2 | 1 | 1 | - Отправляем Васе по вторникам почту
...
20 | 300 | 1 | 10 | 1 | 1 | - Отправлять Саше задание 1
21 | 300 | 1 | 11 | 1 | 1 | - Отправлять Саше задание 2
22 | 300 | 1 | 12 | 1 | 1 | - Отправлять Саше задание 3
23 | 300 | 2 | 11 | 1 | 1 | - Отправлять Пете задание 2
23 | 300 | 3 | 10 | 1 | 1 | - Отправлять Васе задание 1
Запрос

select 
  u.name as usr,
  p.name as pname,
  x.value as val
from users u 
left join xval x on x.user_id = u.id and x.concept = 200
left join param p on p.id = x.param_id
where u.id = 1

вернет вам все параметры отправки почты (concept=200) для Саши.
USR | PNAME | VAL
Саша | Отправлять в пн | 1
Саша | Отправлять во вт | 1
Саша | Отправлять в ср | 1
Нужно узнать, какие конкретно отправлять задания?
Просто меняете концепт на 300 и результатом будут все задания на отправку для Саши.

Добавить какой-то параметр? Просто добавляете строку в таблицу и все!
И никаких правок структуры в продакшене и другого геморроя.

масштабирование этих настроек (I want to believe) не планируется и вроде как можно сделать жестко.

Очень надеюсь, что опытные архитекторы, или те, кто имел дело с подобным, подскажут как быть.

Не верьте, и масштабирование будет и изменения (разве что, количество дней недели не поменяется в ближайшее время). Поэтому, позаботьтесь о себе сейчас - сделайте гибко.

Алгоритм прост:

1. Делаете максимально удобное в плане доработки решение
   
2. Пользуетесь
   
3. Собираете фидбек
   
4. Формулируете список изменений, используя в качестве обоснования конкретные проблемы текущей реализации
   
5. Переходите в начало цикла
   

Обратите внимание, что алгоритм подразумевает, что вы сами решаете, что именно в вашем случае означает "удобное в плане доработки".
Здесь есть два полюса:

• Делаем все максимально оптимизировано, полностью отказываемся от гибкости. При изменении требований делаем все изменения руками программистов, с конвертацией данных.
  
• Делаем все максимально гибко, полностью отказываемся от оптимизации производительности. При изменении требований все делается через конфиги, труд программиста не требуется.
  

Нужно понимать, что и первый и второй вариант дороги для заказчика и прибегать к ним имеет смысл только в том случае, если в этом есть реальная необходимость. Чаще всего используется некий промежуточный вариант.