Jak należy powtarzać zadania kalendarza w bazie danych?

To jest dla małego osobistego projektu dla mikro-zarządzania. Zasadniczo przechowuję zadania w bazie danych SQLite3, która wygląda następująco:

    id INTEGER PRIMARY KEY AUTOINCREMENT
    label TEXT
    deadline INTEGER

Każde zadanie ma termin (termin), który jest przechowywany jako uniksowy znacznik czasu. Jak dotąd tak dobrze, mogę robić wpisy takie jak „jutro: odwiedź babcię”, a nowy wiersz zostanie utworzony z „wizyta babci” jako etykietą, a jutro przekształci się w czas uniksowy na termin.

Teraz chciałbym wprowadzić nowy rodzaj zadań: procedury - zadania powtarzane według schematu czasowego, takie jak „codzienna: czysta kuchnia”. Jak można przechowywać lub modelować takie zadania?

Na razie myślę, że w przypadku zadania, które należy wykonywać codziennie, generowanie nowych wierszy w mojej tabeli, które będą miały tę samą etykietę, a pole terminu będzie zwiększane o jeden dzień. W takim przypadku muszę ustalić limit w przyszłości. Na przykład, jeśli tworzę rutynę na każdy dzień, tworzy ona nowy wiersz na co dzień w pozostałym roku.

Czy istnieje prostszy sposób na zrobienie tego? Czy brakuje mi oczywistych zasad projektowania baz danych?

Możesz zrobić osobny stolik do ponownego powtarzania. Ale szczerze mówiąc, chciałbym umieścić je w tym samym stole z polem typu.

Coś takiego:

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 

Oprócz komentarza S.Lott Martin Fowler - Cykliczne wydarzenia dla kalendarzy PDF może ci pomóc (uważam to za trochę trudne).

Zauważ też, że kilka narzędzi interfejsu użytkownika oferuje opisywaną funkcję od razu po wyjęciu z pudełka (z prostym modelem zadania). Uważam ten problem za trudny do rozwiązania problem z projektowaniem baz danych bez takich narzędzi.

Moim zdaniem są dwie opcje:

• Przechowuj dużą liczbę równych rzędów dla powtarzających się przedmiotów, jednak muszą one się zakończyć (albo do końca, albo do skończonej liczby przedmiotów) i muszą być oznaczone jako powtarzające się przedmioty. Kiedy zmieniasz zdarzenie, musisz je wszystkie zaktualizować, ale jeśli chcesz raz zboczyć, możesz po prostu „zerwać” połączenie między jednym zdarzeniem i ustawić je jako normalne.
• Zachowaj zdarzenie jako powtarzający się przedmiot, z pewnym schematem powtórzeń, i oblicz dla określonej daty, które powtarzające się przedmioty są należne w danym dniu. Daje to możliwość nieskończonego powtarzania.

Jeśli jest to projekt osobisty i chcesz po prostu przechowywać swoje zadania, polecam TaskCoach . Jest to aplikacja komputerowa, wieloplatformowa, open source, łatwa do uruchomienia i posiadająca naprawdę dobre funkcje.

W przypadku opracowywania aplikacji zadań najbardziej prawdopodobnym sposobem jest dodanie nowego wiersza dla każdego powtarzającego się zadania. Logika polega na tym, że każde zadanie samo w sobie jest odrębnym bytem i musi zostać zakończone przed rozpoczęciem tego samego zadania następnego dnia. Jeśli tylko zwiększysz to, nie możesz przechwycić historii zadania.

Jeśli uważasz, że dałoby to dużą listę, gdyby kilka zadań nie zostało ukończonych, możesz wywołać zdarzenie po zakończeniu zadania cyklicznego, aby nowe zadanie zostało wygenerowane jako nowy wiersz tylko wtedy, gdy zadanie jest oznaczone jako ukończone. Jak zasugerował Morons, możesz użyć oddzielnej tabeli z flagą dla powtarzających się zadań w oryginalnej tabeli wraz z danymi dla powtarzalności (dni, tygodnie, czas powtarzania), abyś mógł mieć prosty skrypt, który mógłby generować powtarzające się zadania w oparciu o data lub warunek lub etykieta.

Ale jeśli masz pewność, że zadanie jest z pewnością powtarzalne bez żadnych zmian (np. Pędzel codziennie) i nie wymaga obszernego śledzenia, możesz po prostu wypróbować następującą strukturę

• Flaga powtarzania - wskazująca, że ​​zadanie się powtarza
• Okres powtarzalny - dzień, tydzień, miesiąc
• Liczba utworzonych zadań - zwiększyłoby to zadanie w oparciu o okres powtarzania się. Jeśli więc zadanie zacznie się dzisiaj i będzie miało okres jednego dnia, zwiększy się o jutro
• Liczba zakończonych zadań - zwiększy się, jeśli zadanie zostanie ukończone

Logika polega na tym, że różnica między zakończonymi zadaniami a utworzonymi zadaniami powinna być zawsze okresem powtarzania się, jeśli zadanie jest zawsze ukończone. Tak więc podzielenie różnicy dni przez okres powtarzalny dałoby wskazanie, jak długo zadanie jest w toku.

Dzięki za Kareem za zwrócenie na to uwagi

IMHO, aplikacje zadań są trudne do zbudowania dla ogółu ludzi.

Zdecydowanie najczęstszą operacją będzie spisanie wszystkich zdarzeń występujących w danym okresie czasu. Zoptymalizuj więc swoje dane, aby na to pytanie można było odpowiedzieć prostym zapytaniem SQL. Utworzyłbym dwie tabele:

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 ...);

Indeksuj tabelę zdarzeń według czasu rozpoczęcia i zakończenia. Następnie na wszystkie zapytania można bardzo szybko odpowiedzieć z tabeli zdarzeń. Kiedy edytujesz cykl, po prostu usuń i ponownie utwórz wszystkie odpowiednie zdarzenia.

Ta rada jest bezwstydnie powtarzana z książki Toma Kite'a.

Powtarzane zadania powinny mieć datę początkową i końcową. W przypadku zadania z jedną datą byłyby to ta sama data.

Utwórz tabelę „Daty”, która ma jeden rekord na każdy dzień, który według Ciebie jest istotny od początku twoich potrzeb, aż do przyszłości, jak chcesz: na przykład 12/31/2100 i przekonwertuj na swój format.

Zapytanie może wyglądać następująco:

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]

Zrobiłem coś podobnego lata temu, implementując interfejs, taki jak Windows Task Scheduler, i zasadniczo dla każdego zadania masz StartDate, EndDate (może być zerowy), StartTime i RecurringDays, które zawierają dni tygodnia, w których zadanie musi być zaplanowane.

Możesz użyć dwóch tabel: jednej do opisu zadań, drugiej do ich statusu (wykonano / nie wykonano, i innych informacji: czasu spędzonego, statusu wyjścia, lokalizacji pliku dziennika itp.) Tabela opisu zawierałaby nazwa zadania oraz data lub częstotliwość, z jaką powinno ono być uruchamiane: na zadanie przypadałby tylko jeden wiersz. Każdego dnia proces wypełniałby tabelę statusu dla zadań do wykonania dzisiaj, z tabeli opisu (można wypełnić tydzień lub miesiąc wcześniej).

Programowe generowanie tabeli stanu zapewnia elastyczność, jakiej potrzebujesz dla częstotliwości (np. „Każdego dnia tygodnia z wyjątkiem dni ustawowo wolnych od pracy dla kraju X” - może być nawet przechowywany jako ciąg znaków). Posiadanie tabeli statusu pozwala sprawdzić, czy i jak często zadania się nie udają (na przykład: „Miałem uruchamiać się codziennie: jak często miałem na to czas?”).