Как хранить настройки регистрации?

Question

[Dos]

Знаю, что вопрос уже «избитый», но не могу для себя решить как хранить настройки регистрации на мероприятия. Помогите!

Есть мероприятия. У этих мероприятий есть различные виды регистраций: конкурс, батлы, мастер-класс и так далее. У каждой из этой регистрации есть изменяемые настройки и значения «по-умолчанию»:

• Дата начала регистрации
  
• Дата окончания регистрации
  
• Тип калькулятора стоимости
  
• Валюта
  
• Максимальное количество регистраций
  
• Показывать виджет списка регистраций
  
• Показывать количество участников
  
• и так далее.
  

Настройки регистрации пользователь выбирает сам или используются по-умолчанию.
1. Где хранить подобные данные в MySQL или в noSQL?
2. В каком виде хранить такие данные?
3. Какая должна быть архитектура, если используется MySQL хранилище?

Возможно где-то есть хорошая статья, где разобран вопрос исходя из различных задач. Буду очень благодарен за ссылки!

Answer 1

[grinat]

Одна таблица сам евент с датой/валютой и прочей херней которая у всех идентична. Другая таблица id поля, название, тип. Третья с id eventa, id поля настроек, значение поля. https://designpatternsphp.readthedocs.io/ru/latest...

Answer 2

[Игорь]

Для начала, какой стек технологий планируете использовать?

Как хранить, вопрос риторический отчасти.

Если ближе к делу, то ...
-----------------------------------------------------
Вам нужно продвинуться в сторону ORM.
Работать с сущностями, сложного нечего нет.

Прочтите немного, что-нибудь про ORM.

Плюсы.
- Работа с данными в виде объектов.
- Ускорение разработки

например, вам нужно сохранить какие-нибудь настройки, вы делаете так:

$setting = new Setting();
$setting->setCount(12);

$sub_settings = new SubSettings();
$setting->setSubSettings($sub_settings); // и даже так

$em->persist($setting);
$em->persist($sub_settings);

$em->flush();

И всё, ваши данные в базе, со всеми отношениями.

Нужно получить данные, снова достаёте их, и работаете как с объектами.

Может показаться сложным, но только первые пару дней.
После, вопросы, "как хранить настройки регистрации на мероприятия" сами собой отпадут.

Моё субъективное мнение.

Comments

[Dos]

То что нужно) Давно использую ORM, а именно доктрину. Использую на Symfony. Тут вопрос больше не про то, как это сохранить, а про архитектуру. Можете показать что у вас в new Setting(); и new SubSettings()?

[Игорь]

pro-dev, конкретно у меня нет такой сущности.

Если вы используете ORM очевидно, что вы что-то храните.

Создайте сущьность с
-------------------------------
Дата начала регистрации
Дата окончания регистрации
Тип калькулятора стоимости
Валюта
Максимальное количество регистраций
Показывать виджет списка регистраций
Показывать количество участников
и так далее.

Установить отношения one to one например к сущьности User

[Dos]

Игорь,
1. а если таких полей будет много? У нас сущность будет большая...
2. Когда привязывать к пользователю настройки? Во время создания?

[Игорь]

pro-dev, Проведите аналогию.
Что мы делаем, если к продукту привязанно несколько изображений?

А теперь представьте, что вместо изображений, уникальные параметры, причем для каждого юзера

[Игорь]

pro-dev, много это сколько?

[Евгений Ромашкан]

pro-dev,

а если таких полей будет много? У нас сущность будет большая...

Декомпозировать на несколько сущностей.

Answer 3

[Gip]

в базе данных

Comments

[Dos]

Это понятно. А в каком виде?

[Gip]

pro-dev, что в каком виде? мне за тебя DDL таблицы разработать?

[Artem Ivanov]

pro-dev, в табличном)

[Dos]

Artem Ivanov, Gip почему нужно обязательно высмеивать и почему это на тостере так ценится? Понимаю, что хранить в базе данных. Что хранить нужно в таблицах. Вопрос не об этом. Вопрос об архитектуре этих таблиц. Какие они должны быть?

Я так понимаю это должно выглядеть примерно так:

competition //таблица соревнований
competition_settings // таблица настроек
  - competition_id
  - reg_start
  - reg_end
 .... etc

Или же

competition //таблица соревнований
competition_settings// таблица настроек
-id
- name
- default
competition_setting_assignments // таблица настроек соревнований
  - competition_id
  - setting_id

Или вообще в json

competition //таблица соревнований
- id
- settings (json)

[Daria Motorina]

Gip, это не очередной вопрос 'не работает ajax' или 'как вайти в айти', поэтому не выделывайся, это не место для слива негатива за день. За стопку пассивно-агрессивных комментов ловится бан

[Dos]

Daria Motorina, поддерживаю. Тостер превращается в юморной сервис.

[Шохрух Шаймардонов]

pro-dev, Зависит от вашего бд. Если реляционная (mysql, postgresql...) бд то таблички, если nosql(mongo и все такое) то json. А лучше всего немного посидеть почитать теорию, чтобы самому разобраться какой вариант вам подойдет лучше всего

[Gip]

Daria Motorina, а по-моему абсолютно такой вопрос. из автора клещами пришлось вытягавть то что он хочет. в итоге я оказался прав. автор хочет чтобы за него разработали структуру таблиц. никаких целенаправленных вопросов изначально задано не было.
почему он потом что-то осмысленное, вдруг написал?

в итоге - сам автор тролль, провоцирующий на подобные ответы комьюнити.

[Dos]

Шохрух Шаймардонов, благодарю за ответ по делу. Вот я и сам не знаю что лучше выбрать. Сейчас использую mysql. Планирую перейти на postgresql. nosql не рассматривал. Возможно имеет смысл и использовать что-то из этого. Ранее не приходилось решать подобные задачи, поэтому с вопросом пришёл на тостер. Всегда удавалось решать пару полями в базе данных, но тут хотелось бы гибкости и настроек будет больше чем два.

Можете подсказать где лучше почитать про эту тематику? Возможно где-то разбирают плюсы минусы разных вариантов. С удовольствием изучил бы подобную тематику.

[Шохрух Шаймардонов]

pro-dev, ну если честно с бд сам относительно недавно начал работать. Поэтому не могу подсказать "из своей личной коллекции" но правильно заданный вопрос уже пол ответа. Так что как уже тут отвечали сначала разберите все нюансы: сколько пользователей у приложения, какая пиковая нагрузка и т.д. и потом уже задайте гуглу конкретный вопрос. Я сам по сути пока только на mysql. Поэтому с nosql врядли помогу, но с реляционными постараюсь, если возникнут вопросы