doc/Добавил информации про проект (#2)

* doc/Добавил информации про проект

* doc/Добавил размышления про 3нф команд пользователей

* doc/Добавил размышления базу данных + ее содержание + примерная схема бд

docs/api/requests.md

@@ -0,0 +1,53 @@
+# POST (create)
+## user
+1. /auth/register (user): зарегистрировать пользователя.
+2. /auth/login (user): вход в приложение. 
+3. /auth/logout (user): выход из приложения.
+
+## cf user
+1. /cf/user (cf_user): добавить пользователя с платформы codeforces.
+
+## cf users team
+1. /cf/teams (team): добавить команду пользователей платформы codeforces.
+
+## groups
+1. /groups/solo (group): создать группу cf пользователей.
+2. /groups/team (group): создать группу команд cf пользователей.
+
+# GET (read)
+## cf user
+1. /cf/user (id): получить пользователя с платформы codeforces по id в нашей БД.
+
+## cf users team
+1. /cf/teams (id): получить команду пользователей платформы codeforces  по id в нашей БД.
+
+## groups
+1. /groups/solo (id): получить группу cf пользователей  по id в нашей БД.
+2. /groups/team (id): получить группу команд cf пользователей по id в нашей БД.
+
+# PUT (update)
+
+## cf user
+1. /cf/user (cf_user): обновить пользователя с платформы codeforces.
+
+## cf users team
+1. /cf/teams (team): обновить команду пользователей платформы codeforces.
+
+## groups
+1. /groups/solo (group): овить группу cf пользователей.
+2. /groups/team (group): обновить группу команд cf пользователей.бно
+
+# DELETE (delete)
+
+1. /auth/{id}: удалить пользователя под его id + удалить все его группы.
+
+## cf user
+1. /cf/user (id): удалить пользователя с платформы codeforces.
+
+## cf users team
+1. /cf/teams (id): удалить команду пользователей платформы codeforces.
+
+## groups
+1. /groups/solo (id): удалить группу cf пользователей.
+2. /groups/team (id): удалить группу команд cf пользователей.бно
+

docs/dataModel/db_schema.md

@@ -0,0 +1,41 @@
+# Variant 1
+
+## Таблицы
+
+t_users:
+1. id - pk, int 
+2. c_login - not_null, unique, string
+3. c_hashed_password - not null, string
+
+t_cf_users_team_groups:
+1. id - pk, int
+2. c_user_id - fk на t_user (id), int
+3. c_name - not null, string
+4. с_time - not null, timestamp
+
+t_cf_teams: hard_code
+1. id - pk, int
+2. c_first_user (login) - string
+3. c_second_user (login) - string
+4. c_third_user (login) - string
+5. c_group_id - fk на t_cf_users_team_group (id), int
+6. c_name - not null, string
+7. c_description - string
+8. с_time - not null, timestamp
+
+t_cf_users_groups:
+1. id - pk, int
+2. c_user_id - fk на t_user (id), int
+3. c_name -  not null, string
+4. с_time - not null, timestamp
+
+t_cf_users:
+1. id - pk, int
+2. c_cf_login - not null, string
+3. c_cf_user_group_id - fk на t_cf_user_group(id), int
+4. c_description - string
+5. с_time - not null, timestamp
+
+# Примерная схема (не самая красивая)
+
+![context](../assets/db_base_schema.png)

docs/dataModel/modelReview.md

@@ -0,0 +1,51 @@
+# База
+Приложение для спортивных программистов.
+
+Основная аудитория: пользователи [codeforces](https://codeforces.com/)
+
+Проблема: сложно следить за результатами "друзей" (чем их больше, тем сложнее следить за их прогрессом). 
+
+Идея: сделать приложение, которое бы упростило мониторинг результатов "друзей". 
+
+Базовая идея: дать возможность разделять "друзей" на группы и мониторить эти группы.
+
+
+F1: В самой базовой версии будем мониторить рейтинг пользователей, так как рейтинг - самое главное 
+на платформе [codeforces](https://codeforces.com/).
+
+F2: Олимпиады по спортивному программированию делятся на два вида: одиночные и командные. В командных участвуют 
+по 3 человека. Есть смысл оценивать рейтинг таких команд по [примеру](https://codeforces.com/blog/entry/129887), 
+то есть добавить возможность мониторить команды пользователей.
+
+PS: Пользователи нашего API = User; пользователи Codeforces = CF_USER
+
+# Модели:
+## Пользователь (User) нашего приложения:
+### Данные:
+1. Логин в нашем веб-приложении.
+2. Логин на платформе Codeforces? 
+3. Хэшированный пароль.
+
+### Возможности:
+1. Регистрация/ авторизация.
+2. CRUD групп CF_USER и групп команд CF_USER.
+
+## Группа CF_USER
+### Данные:
+1. CF_USER'ы группы.
+2. Автор (User) группы.
+
+## Группы команд CF_USER
+### Данные:
+1. Команды CF_USER'ов группы.
+2. Автор (User) группы.
+
+## CF_USER
+### Данные:
+1. Логин CF_USER на платформе Codeforces.
+2. Рейтинг CF_USER на платформе Codeforces. ? 
+
+## Команды CF_USER
+### Данные:
+1. Состав команды из CF_USER.
+2. Название команды.

docs/other/remark.md

@@ -0,0 +1,39 @@
+R1: Рейтинги на [codeforces](https://codeforces.com/) обновляются после каждого раунда. Раунд бывают 1-2 раза в неделю. 
+Как хранить и обновлять рейтинг пользователей в нашем приложении? 
+Как будто самый простой вариант = кэшировать данные для анализа (рейтинг). После раунда рейтинг обновляется в течение 
+24 часов. Будет кэшировать данные на 24 часа. Нет смысла хранить эти данные в бд? Они хранятся в кэше.
+
+R2: Пробовать сделать "вход" через Codeforces? Нет такого метода в [Codeforces API](https://codeforces.com/apiHelp) :(.
+
+R3: Один CF_USER может быть в нескольких разных командах. Как стоит хранить команды? Как проверить, что команда есть в бд?
+
+R4: Дать возможность USER дать какое-то краткое описание CF_USER, которых он к себе добавил. Проблема: Саша добавил 
+Машу в друзья (ne_masha). Спустя несколько месяцев Саша забыл, кто такой ne_masha. Идея: если было бы краткое описание, 
+то Саша вспомнил бы, что ne_masha - это Маша.
+
+R4: Использовать jwt токены? jwt токен нужен для методов create, update, delete, logout. Без jwt можно register + login.
+
+R5: Потрачу все свои силы на backend часть (скорее всего не будет красивого интерфейса). Postman наше всё!
+
+Q1: Приводить ли к 3НФ команды? Как будто для простоты работы не стоит этого делать. Потому что слишком сложно и 
+непонятно, как с этим работать.
+
+Плохой вариант ?: 4 таблицы: user - user_groups - teams - cf-users (храним по отдельности все данные, потом пытаемся
+все построить в одного монстра) 
+Хороший вариант ?: 3 таблицы: user - user_groups - cf-users-team (? не так много данных для конструктора монстра, 
+то есть мы просто храним объединенную команду, делаем 1 таблицу, вместо 2: cf_user_team (хранит id, название команды, 
+состав команды из 3 участников), против team (id, название команды) + team_cf-users(id, fk team id, fk user id))).
+Также будет потрачено меньше запросов для создания нашего монстра. Это все круто работает до тех пор, пока команды 
+состоят только из 3 человек. Жесткая привязка к лимиту в 3 человека. Но это слишком привлекательно... Если делать 
+полное 3нф, то как будто надо будет добавить еще таблицы для описания команды, хранения порядка, в котором были добавлены
+пользователи в группу. Получается как будто еще минимум нужно 2 таблицы, а желательно даже 4. Слишком много таблиц для 
+такого задания. Будет хардкодить :).
+
+
+Q2: Может нет смысла хранить пользователя как можно более абстрактно? Не делать 3нф, сделать привязку к user.
+В кэше хранить дополнительные данные.
+
+Q3: Надо же хранить как-то порядок пользователей в его группе? Или просто по времени добавления?
+
+
+

docs/requirements/requirements.md

@@ -0,0 +1,9 @@
+# База:
+
+## Функциональные требования:
+1. Должна быть возможность зарегистрироваться и войти в приложение.
+2. У пользователя должна быть возможность создавать группы из пользователей платформы
+[codeforces](https://codeforces.com/) и из команд таких пользователей. P.S. В команде от 1 до 3 человек + ее название.
+3. У пользователя должен быть полный CRUD с его группами.
+4. У пользователя должна быть возможность дать какое-то краткое описание тому, что он добавляет (одного пользователя 
+или сразу всю группу).