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

В web-проекте типа фриланс-биржи требуется организовать у пользователей настройку получения рассылок. Настройки эти - просто true/false, но их более 30. Что хорошо - масштабирование этих настроек (I want to believe) не планируется и вроде как можно сделать жестко.

Проблема заключается в том, что по ним нужно производить поиск. Прочитав это обсуждение, появился соблазн засунуть их отдельными полями в таблицу пользователей. Но в ней сейчас порядка 40 полей, и пихать еще 30 просто каких-то булевых настроек мне пока совесть не позволяет.

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

Чтобы было понятно, постараюсь объяснить примерно как они выглядят.
Дни недели (по каким получать рассылки): 7 булевых значений.
Бюджет заданий (какие задания должны приходить на почту): еще 5 значений вида от i до j

И так далее еще всякие разные условия.

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

Таблица концептов(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 и результатом будут все задания на отправку для Саши.

Добавить какой-то параметр? Просто добавляете строку в таблицу и все!
И никаких правок структуры в продакшене и другого геморроя.
Ответ написан
alexey-m-ukolov
@alexey-m-ukolov Куратор тега Веб-разработка
масштабирование этих настроек (I want to believe) не планируется и вроде как можно сделать жестко.

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

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

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

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

Нужно понимать, что и первый и второй вариант дороги для заказчика и прибегать к ним имеет смысл только в том случае, если в этом есть реальная необходимость. Чаще всего используется некий промежуточный вариант.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
swanrnd
@swanrnd
Издатель HTML5 игр
Для поиска лучше всего булевое поле + индекс. По этому лучше всего искать.
Для хранения лучше побитово:
1 - настройка1
2 - настройка2
4 - настройка3
6 - настройка2+3
Ответ написан
Комментировать
zo0m
@zo0m
full stack developer
я бы сделал таблицу: user_id, param_name, param_value, и не выдумывал
индексы только расставьте, user_id полюбому, и может быть param_name(если выборки по параметру будут)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы