Модель базы данных повторяющихся событий

Question

Я искал решение для повторяющихся событий, поэтому я нашел два подхода:

Первый подход:

Создайте экземпляр для каждого события, поэтому, если у пользователя есть ежедневное событие на один год, в таблице потребуется 365 строк. Это звучит правдоподобно для фиксированного периода времени, но как бороться с событиями, которые не имеют конечной даты?

Второй подход:

Создать таблицу шаблонов Reccuring, которая создает будущие события во время выполнения, используя какое-то временное выражение (Мартин Фаулер).

Есть ли причина не выбирать первый подход вместо второго? Первый подход заключается в перенаселении базы данных и может повлиять на производительность, верно?!

Есть цитата о подходе № 1, которая гласит:

«Хранение повторяющихся событий в виде отдельных строк - путь к катастрофе». (https://github.com/bmoeskau/Extensible/blob/master/recurrence-overview.md)

Что вы, ребята, думаете об этом? Я хотел бы получить представление о том, почему это будет катастрофой.

Я ценю вашу помощь

Answer 1

Храните событие календаря как правило , а не как материализованное событие.

Хранение повторяющегося события, материализованного в виде строки, является поводом для катастрофы по очевидной причине, что материализация в идеале должна быть бесконечной длины. Поскольку таблица бесконечной длины невозможна, разработчик попытается воспроизвести это поведение с помощью некоторого умного, непонятного трюка, что приведет к ошибочному поведению приложения.

---

Мое предложение: сохраняйте правила, материализуйте их и добавляйте в виде строк, только при запросе, что приводит к гибридному подходу.

Таким образом, у вас будет две таблицы для хранения вашей информации, во-первых, для хранения правил, во-вторых, для хранения строк, материализованных из любого правила в таблице правил.

---

Общие рекомендации могут быть:

• Для одноразового события добавьте строку во вторую таблицу.
• Для повторяющегося события добавьте строку в первую таблицу и материализуйте часть во вторую таблицу.
• Для запроса о будущей дате материализуйте правила и сохраните их во второй таблице.
• Для модификации конкретного экземпляра повторяющегося события материализуйте событие до экземпляра, который вы хотите изменить, а затем измените последний экземпляр и сохраните его.
  • Далее, если событие слишком далеко в будущем, не материализуйте его. Вместо этого сохраните его как правило и выполняйте позже, когда придет время.

---

Простых таблиц будет недостаточно для хранения того, что вы пытаетесь сохранить. Хранение такого рода информации в базе данных лучше всего поддерживается, если поддерживается хранимыми процедурами для доступа и изменений.

Answer 2

Правильный ответ на самом деле оба, и не либо или .

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

Теперь, объединяясь с каким-то шаблоном повторенияв SQL будет очень большая боль в шее.Кроме того, что если ваши правила позволяют вам настраивать (редактировать или даже удалять) конкретные экземпляры этого шаблона повторения?

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

Рассмотрите инструмент для составления календаря, такой как Outlook или Календарь Google.Эти приложения используют этот подход.Вы можете перемещать или редактировать экземпляр.Вы также можете изменить всю серию.Приложения спрашивают вас, что вы хотите делать, когда переходите в режим редактирования.

Существуют некоторые ограничения для этого.Например, если вы редактируете экземпляр, а затем редактируете шаблон, вам необходимо иметь правило, которое гласит: (а) выигрывает новый родитель или (б) всегда выигрывают модифицированные потомки.Я думаю, что Outlook и Google Calendar используют подход (a).

Что касается того, почему каждый экземпляр записан явно, единственная катастрофическая вещь, о которой я могу думать, это то, что если у вас нетПо ссылке обратно на исходный шаблон повторения у вас будет чертовски много времени отменить всю серию одним действием.

Назад к без даты окончания - Это может быть случай усмотрения, являющегося лучшей частью доблести и использующего какое-то эмпирическое правило, которое накладывает практический предел того, как далеко в будущееВы расширяете такой ряд - или, альтернативно, вы можете просто не допустить такого правила в шаблоне.Завершите шаблон и позвольте создателю правила беспокоиться о его расширении в будущем, когда это станет необходимым.