Як повинні повторювані завдання календаря зберігатися в базі даних?

Це для невеликого персонального проекту з мікроуправління. В основному я зберігаю завдання в базі даних SQLite3, яка виглядає приблизно так:

    id INTEGER PRIMARY KEY AUTOINCREMENT
    label TEXT
    deadline INTEGER

Таким чином, у кожного завдання є встановлений термін (термін), який зберігається як часовий штамп Unix. Поки що добре, я можу робити записи, такі як "завтра: відвідай бабусю", і новий рядок буде створений з "відвідувати бабусю" як мітку, а завтра трансформований як термін для Unix.

Тепер я хотів би ввести нові типи завдань: підпрограми - завдання, які повторюються за тимчасовим шаблоном, як "щодня: чиста кухня". Як такі завдання можна зберігати чи моделювати?

На даний момент я думаю, що у випадку завдання, яке потрібно виконувати щодня, генерувати в моїй таблиці нові рядки, які мали б ту саму мітку, а поле граничного терміну збільшується на один день. У цьому випадку мені потрібно встановити ліміт у майбутньому. Наприклад, якщо я створюю розпорядок дня на кожен день, він створює новий рядок для кожного дня, що залишився.

Чи є простіший спосіб зробити це? Я пропускаю якісь очевидні принципи проектування бази даних?

Ви можете зробити окрему таблицю для повторного повторення. Але, чесно кажучи, я хотів би покласти його в ту саму таблицю з полем Type.

Щось на зразок цього:

ID - Int Pk

TaskDescription - TEXT

Type - Text - (Re-Occurring, or Single Occurrence) 

Due- TimeStamp - for Single Occurrence is the Date time

LastTimeCompleted - Time Stamp

ReoccurringUnit - Text - "Days", Weeks, Month, Ext

ReoccurringEveryX - Int - Reoccurring interval 

Окрім коментаря С.Лотта, Мартін Фаулер - Події, що повторюються для календарів PDF, можуть допомогти вам (мені це було трохи складно).

Також зауважте, що кілька інструментів користувальницького інтерфейсу пропонують функцію, яку ви описуєте поза коробкою (із простою моделлю завдань). Я б розглядав цю проблему як важко вирішити проблему проектування бази даних без таких інструментів.

На мій погляд, є два варіанти:

• Зберігайте велику кількість рівних рядків для повторюваних елементів, однак вони повинні закінчуватися (або через кінцеву дату, або з обмеженою кількістю предметів), і повинні бути позначені як повторювані елементи. Коли ви змінюєте подію, вам доведеться оновити їх усі, але коли ви хочете один раз відхилитися, ви можете просто "перервати" зв'язок між однією подією і зробити це звичайною подією.
• Зберігайте подію як елемент, що повторюється, з певною схемою повторення, і обчисліть для даної дати, які повинні повторюватись елементи на дату. Це дає можливість нескінченного повторення.

Якщо це особистий проект, і ви просто хочете спосіб зберігати свої завдання, я рекомендую TaskCoach . Це настільний додаток, багатоплатформа, відкритий код, легко розпочати роботу та мати справді хороші функції.

Якщо ви розробляєте програму завдань, найімовірнішим способом є додавання нового рядка для кожного повторюваного завдання. Логіка полягає в тому, що кожне завдання є окремим об'єктом саме по собі, і воно має бути виконане до того, як це ж завдання розпочнеться наступного дня. Якщо ви просто збільшуєте його, ви просто не можете зафіксувати історію завдання.

Якщо ви вважаєте, що це просто дасть вам великий список, якщо кілька завдань не було виконано, ви можете викликати подію, як тільки повторюване завдання буде виконано, так що нове завдання буде генеровано як новий рядок лише тоді, коли завдання буде позначено як завершено. Як запропонував Моронс, ви можете використовувати окрему таблицю з прапором для повторюваних завдань у вихідній таблиці разом з даними для повторення (дні, тижні, час повторення), щоб ви могли просто мати простий скрипт, який може генерувати повторювані завдання на основі дата або стан або за етикеткою.

Але якщо ви впевнені, що завдання напевно повторюється без будь-яких змін (наприклад, кисть щодня) і не потребує широкого відстеження, то ви можете просто спробувати наступну структуру

• Прапор повторення - вказує на те, що завдання повторюється
• Період повторення - день, тиждень, місяць
• Кількість створених завдань - Це збільшить завдання на основі періоду повторення. Отже, якщо завдання розпочнеться сьогодні і має повторний період одного дня, воно би зросло на завтра
• Кількість виконаних завдань. Це збільшується, якщо завдання буде виконано

Логіка полягає в різниці між виконаними завданнями і створеними завданнями повинні бути завжди періодичними, якщо завдання завжди виконується. Отже, розділення різниці днів на період повторення дасть вам змогу вказувати на те, як довго ця задача очікується.

Дякуємо Kareem за те, що вказав на це

IMHO, додатки для завдань важко створити для людей взагалі.

На сьогодні найчастішою операцією буде перелік усіх подій, що відбуваються за певний проміжок часу. Тож оптимізуйте свої дані, щоб відповісти на це запитання простим запитом SQL. Я створив би дві таблиці:

CREATE TABLE events(start TIMESTAMP, end TIMESTAMP, name TEXT, user_id LONG,
                    recurrence_id LONG, ...);
CREATE TABLE recurrences(id LONG, start TIMESTAMP, end TIMESTAMP, name TEXT, 
                         frequency ...);

Індексуйте таблицю подій за часом початку та закінчення. Тоді всі запити можна відповісти з таблиці подій дуже швидко. Коли повтор буде відредаговано, просто видаліть і відтворіть усі відповідні події.

Ця порада безсоромно повторюється з книги Тома Кайте.

Повторні завдання повинні мати дату початку та дату закінчення. Для одного завдання на дату вони будуть однаковою датою.

Створіть якусь таблицю "Дати", яка має один запис на кожен день, який, на вашу думку, є актуальним з початку ваших потреб, аж до майбутнього: наприклад, 31.12.2100 та перетворіть у ваш формат.

Запит може виглядати так:

Select 
  t.id
  , t.label
  , d.UnixDate
from Tasks as t
inner join Dates as d
on d.UnixDate >= t.StartDate
  and d.UnixDate <= t.EndDate
where t.id = [ID Param]

Я робив щось подібне років тому, реалізуючи інтерфейс, такий як Планувальник завдань Windows, і в основному для кожної задачі у вас є StartDate, EndDate (може бути нульовою), StartTime і RecurringDays, що містить дні тижня, коли завдання має бути заплановано.

Ви можете використовувати дві таблиці: одну для опису завдань, іншу для їх стану (зроблено / не зроблено, та інша інформація: витрачений час, стан виходу, розташування файлу журналу тощо). Таблиця описів містила б назва завдання та дата або періодичність, з якою воно має бути запущене: для кожного завдання буде лише один рядок. Кожен день процес заповнює таблицю статусу для завдань, які потрібно виконувати сьогодні, з таблиці описів (ви можете заповнити на тиждень чи місяць наперед).

Програмна генерація таблиці статусу дає вам всю необхідну гнучкість для частоти (наприклад, "щотижня, крім банківських свят для країни X" - вона навіть може зберігатися як рядок). Наявність таблиці статусу дозволяє перевірити, якщо або як часто не виконуються завдання (наприклад: "Я повинен був виконуватись щодня: як часто я встигав це робити?").