Создание схемы базы данных

[astronik00]

Developing Task

Требования: понимание работы системы, взаимодействия между сервером календарей и клиентом, знание общих принципов построения реляционных баз данных

Краткое описание

Создать в виде диаграммы схему реляционной базы данных для хранения локальной версии списка задач на комьютере пользователя. Описать отношения между таблицами (если их несколько), сделать их оптимальными.

Функциональные требования или документация

ТЗ Представление деревьев

Обобщенное решение

• [ ] Создание схемы в виде диаграммы

Выходной результат

Диаграмма uml в папке Documentation

[astronik00]

@aleksandra-shchegoleva

User хранится в nextcloud в adminpanel Как мне кажется, не хватает сущности Calendar, ServerList:Calendar 1:M

[aleksandra-shchegoleva]

Вопрос от Никиты @Lailes "А name у tasklist что будет хранить?" Ответ: согласно иерархии, которую предложила Катя, это название задачи.

[astronik00]

@aleksandra-shchegoleva Кстати как мне еще кажется, называть таблицы EntityList - это излишество, ибо таблица и так подразумевает под собой список, можно ограничиться просто Enitity, т.е Server, Task

Также поскольку User храниться будет на AdminPanel, не совсем пока известно, в каком формате это будет происходить. Я к тому, что user_id может просто не быть, а например email будет и он же будет идентификатором

И получается, что не хватает еще password в таблице Server

[Lailes]

@aleksandra-shchegoleva Саша, скажи пожалуйста, а когда будет ориентировочно готова данная задача? Хочу взять задачу, но мне необходим результат этой 🤔

[aleksandra-shchegoleva]

@Lailes Думаю, что к среде-четвергу будет готова точно.

[aleksandra-shchegoleva]

@astronik00 В функциональных требованиях (пункт 7) указано, что нужно чтобы была возомжность сохранения логина и пароля пользователя в настройках. Где тогда будут хранится логин и пароль? Просто в форме висеть?

Сущность Calendar нужна, если на сервере календарей более одного календаря рабочего? Разве мы предусматриваем такое?

[aleksandra-shchegoleva]

@astronik00 Загрузила схему примерную. Остается вопрос с сущностью Calendar, с остальным, как мне кажется, все нормально. Думаю после обсуждения можно отправлять на МР.

[aleksandra-shchegoleva]

@astronik00 Обновила схему согласно сущность iCalendar и нашей вчерашней беседе В md файле описала атрибуты для таблицы Task (думаю, что для таблицы Server это не требуется). У меня есть несколько вопросов: 1) В атрибуте category у нас будет всегда одна категория? Если нет, то требуется дополнительная таблица с категориями. 2) Я поменяла тип id у Task - согласно документации у каждой задачи есть UID. Чтобы не хранить лишние данные можно его использовать как id

[astronik00]

@aleksandra-shchegoleva Task ведь хранится в определенном календаре. Насколько я понимаю, задачу мы добавляем не на сервер, а по названию календаря в него же. У тебя в Task хранится server_id, т.е. мы предполагаем, что будет где-то в стороне хранить строку подключения, правильно? Как я могу предположить, пользователь выбирает сервер, выбирает календарь, указывает почту и пароль, мы где-то создаем класс Principal, от которого делаются все запросы, на протяжении всей сессии пользователя. Правильно?

[aleksandra-shchegoleva]

@astronik00 В таблице Server есть атрибут uri - это строка подключения к конкретному календарю. Возможно стоит переименовать сущность в Calendar для большего понимания. Насколько помню, мы решили, что у нас будет такая схема - у каждого сервера один календарь. Поэтому при подлючении по ссылке мы идем напрямую к календарю. Т.е. нет выбора календаря. В моем понимании схема подключения к серверу такая: 1) Пишем название сервера в поле ввода (от руки) 2) По названию сервера в БД ищется ссылка на календарь этого сервера (либо эту ссылку мы тоже вводим от руки) 3) Вводим логин и пароль, 4) Отправляем запрос

По поводу Principal мне нужно некоторое время, чтобы я прочитала про него

Поправь, пожалуйста, если я где-то неправа

[astronik00]

@aleksandra-shchegoleva

Мне кажется, что лучше оставить таблицу с названием Server. Не совсем так, как я поняла

1. Вводим название сервера, почту и пароль.
2. Получаем список календарей с сервера по заданной строке подключения (т.е ссылки на конкретный календарь нет)
3. Если нужен конкретный, то осуществляем поиск (пока не совсем понятно, можно ли это сделать библиотекой Python по имени), но как минимум, можно проверить календари на пустоту и при первом подключении создать новый. Надо проверить возможность поиска календаря по имени, тогда url в таком виде можно не хранить, а сделать таблицу 1 к 1, Server и Calendar, просто имя календаря хранить в Server

[Lailes]

@astronik00 А у нас название задачи уникально?

[Lailes]

@aleksandra-shchegoleva Предлагаю добавить еще одно поле, не хранящееся в CalDAV, а именно время последней синхронизации. Это упростит поиск конфликтов

[Lailes]

@aleksandra-shchegoleva Предлагаю добавить еще одно поле, не хранящееся в CalDAV, а именно время последней синхронизации. Это упростит поиск конфликтов

@astronik00 что думаешь, на счёт этого?

[astronik00]

@Lailes можно, даже если лишними окажутся, проблему не составят

[astronik00]

@Lailes

@astronik00 А у нас название задачи уникально?

Не знаю, это нигде не описано, вроде как

[aleksandra-shchegoleva]

@astronik00 @Lailes Название задачи не является уникальным насколько понимаю. Поле синхронизации добавила. Также добавила поле для хранения ПИН-кода. Обновленная схема

[astronik00]

@aleksandra-shchegoleva, @Lailes

Пин-код создается для пользователя, а не для сервера. В соответствие с твоей схемой пользователь может указать pin для каждого сервера, когда мы обсуждали, что это скорее как идентификатор клиента. Т.е он подключается к серверу nextcloud по email и паролю, в настройках может добавить другие сервера, а также задать пин код, по которому входить вместо email-а и пароля

[aleksandra-shchegoleva]

@astronik00 @Lailes Пин-код хранится вне базы данных? Все же мне кажется нужна сущность User. Как мы будем определять, что пользователь уже авторизирован и какой у него пин-код?

[aleksandra-shchegoleva]

@astronik00 Обновленная схема