MyWackoSite: NsuTs/Documentation/devguide/dbchanges/problems

Рассогласования:

Основные юзкейзы:

  1. Зная user_olympiad вывести все поля, которые привязаны к данному user
  2. Построение рейтинга, очереди и тд для командных олимпиад должно производиться с группировкой по командам

  1. Как хранить команды?
Вариант 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. Как хранить пользовательские данные?
Вариант 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))