Прежде всего, прошу прощения за мой отличный английский, я француз.
Я собираюсь попросить совета по проблеме проектирования базы данных.
Мне нужно спроектировать календарьс событиями.Вкратце, событие включает в себя дату / время начала, дату / время окончания и описание.
Проблема заключается в том, что мне нужно учитывать повторы;при создании события можно указать, что оно начинается на следующей неделе и повторяется до определенной даты или нет.
Я вижу две возможности дизайна:
- создать events таблица с id , start_datetime , end_datetime и description полей.При добавлении нового события мы генерируем столько строк, сколько есть повторяющихся событий.
Преимущества: мы можем сделать SELECT * для извлечения всех событий без конкретного алгоритма.Кроме того, можно изменить описания каждого вхождения события, поскольку они рассматриваются как все разные.
Недостаток (ОСНОВНОЙ!): Если мы не ставим конечную дату так, чтобы она была бесконечнойповторение, мы не будем запоминать бесконечность событий ...
черпают вдохновение из метода, описанного в
этой теме , то есть в двух таблицах:
<b>id description</b>
1 Single event on 2018-11-23 08:00-09:30
2 Repeated event :
* every monday from 10:00 to 12:00 from Monday 2018-11-26
* every wednesday from 2018-11-28 from 14:00 to 14:45 until 2019-02-27
- событие_повторения таблица
<b>id event_id start_datetime end_datetime interval end_date </b>
1 1 2018-11-23 08:00:00 2018-11-23 09:30:00 NULL NULL
2 2 2018-11-26 10:00:00 2018-11-26 12:00:00 604800 NULL
3 2 2018-11-28 14:00:00 2018-11-28 14:45:00 604800 2019-02-27
Примечание : интервал - это числосекунд между вхождениями: 604800 = 24 (часы) * 3600 (секунды) * 7 (дни).
Преимущество: в случае бесконечных повторений (в случае события id 2) у нас очень малоколичество строк для записи и производительность увеличены.
Недостатки: если мы хотим изменить описание события (или других возможных полей) для конкретного события, а не другого, мы не сможем без создания третьей таблицы, event_description например:
<b>id event_id user_id datetime description</b>
1 2 1 2018-11-26 10:00:00 Comment from 2018-11-26
2 2 2 2018-12-03 10:00:00 Comment of the second occurrence, i.e. from 2018-12-03
Примечание : user_id - зарегистрированный пользователь, который написал комментарий.
Еще одним недостатком являетсячтобы получить список событий за данный день, неделю или месяц, запрос выбора будетсложный и использовать соединения.Таблица event_description может иметь очень большие размеры при сотнях тысяч событий.
Мой вопрос: что бы вы посоветовали в качестве более эффективной альтернативы?Может быть, второе решение хорошо?Как вы думаете?
Что касается используемых технологий, я намерен перейти на MySQL, СУБД, которую я знаю лучше всего.Тем не менее, если вы считаете, что использование, например, MongoDB лучше в случае очень большого количества строк, не стесняйтесь сообщать об этом.
Для информации, мое приложение - это API, разработанный с API Platform, поэтому Symfony 4с доктриной ORM.
Заранее благодарю за ответы.