Изменения в базе данных
Концепция:
1.2.8 – Есть команды, которые привязаны к олимпиаде, к туру. Участники команды записываются как обычные данные о команде.
1.3.0 – Есть пользователь.
Он может привязывать себя к различным олимпиадам (создается запись user_olympiad), подставляя себе определенные данные(ФИО, город)
В олимпиадах возможно создавать команды.
Отличия:
- Наличие внешних ключей, каскадное удаление (раньше просто подразумевалась связь)
- Строгое именование таблиц: в каждой таблице id, название таблицы в ед. числе, через подчерк
- Изменение сущностей
Users -> User + User_olympiad
Forms -> Attribute + Olympiad_attribute
Olympiad поле teams_alllowed
Командная / Личная?
Рассогласования:
Основные юзкейзы:
- Зная user_olympiad вывести все поля, которые привязаны к данному user
- Построение рейтинга, очереди и тд для командных олимпиад должно производиться с группировкой по командам
-
- Как хранить команды?
Вариант 1
Создать таблицу team( id, title ...). В таблице user_olympiad есть ссылка user_olympiad.team на team.id
Сценарий работы:
Если олимпиада командная, то выводим список существующих команд и просим либо присоединиться к уже созданной, либо ввести название новой команды.
Если олимпиада личная, то просим ввести ник/логин пользователя, автоматически создаем команду запись в таблице team.
Вариант 2
Поле team ничем не отличается от других атрибутов (ФИО, город), поэтому завести поля в таблице attribute: team_title, login
Сценарий работы:
При создании олимпиады
Если олимпиада командная, то создаем olympiad_attribute c атрибутом team_title.
1) При регистрации это поле будет предложено заполнить, как и другие.
Если человеку уже выслано приглашение вступить в команду, то сразу добавляем для него запись user_olympiad, правда с ключом activate = false. Если он захочет зарегистрироваться, то активируем эту запись, заполняем недостающие поля.
2) При регистрации это поле не заполняется. Заполняется как в 1ом варианте в отдельной вкладке.
- Как хранить пользовательские данные?
Вариант 1
Таблицы user_value_olympiad (user_olympiad, value(int))
user_value (user, attribute, value(string))
Аргументы: для одного user храним только один экземпляр данных, например фио. для каждой олимпиады добавляется запись в user_value_olympiad со ссылкой на значение в табл user_value
Вариант 2
Одна таблица user_value_olympiad (user_olympiad, attribute, value)
Аргументы: т.к. итак по значению user можно найти все его участия в олимпиадах (user_olympiad)
Для того что бы не хранить много одинаковых строковых значений, можно добавить разрешающую таблицу values(value(int), value(string))
