Come devono essere archiviate le attività di calendario ripetitive nel database?

Questo è per un piccolo progetto personale per la micro-gestione. Fondamentalmente, memorizzo le attività in un database SQLite3 che assomiglia a questo:

    id INTEGER PRIMARY KEY AUTOINCREMENT
    label TEXT
    deadline INTEGER

Quindi ogni attività ha una data di scadenza (scadenza) che viene memorizzata come un timestamp Unix. Fin qui tutto bene, posso fare voci come "domani: visita la nonna" e viene creata una nuova riga con "visita la nonna" come etichetta e domani trasformata come tempo Unix per la scadenza.

Ora vorrei inserire un nuovo tipo di attività: routine - attività ripetute secondo uno schema temporale, come "tutti i giorni: cucina pulita". Come è possibile archiviare o modellare tali compiti?

Per il momento, sto pensando che, nel caso di un'attività che deve essere eseguita ogni giorno, generare nuove righe nella mia tabella con la stessa etichetta e il campo di scadenza aumentato di un giorno. In questo caso, ho bisogno di fissare un limite in futuro. Ad esempio, se creo una routine per ogni giorno, crea una nuova riga per tutti i giorni dell'anno rimanente.

C'è un modo più semplice per farlo? Mi mancano alcuni ovvi principi di progettazione del database?

È possibile creare una tabella separata per il ripetersi. Ma onestamente lo metterei nello stesso tavolo con un campo Tipo.

Qualcosa come questo:

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 

Oltre al commento di S.Lott, Martin Fowler - Eventi ricorrenti per calendari PDF può aiutarti (l'ho trovato un po 'difficile).

Si noti inoltre che diversi strumenti dell'interfaccia utente offrono la funzione che si sta descrivendo immediatamente (con un semplice modello di attività). Considererei questo problema come un problema di progettazione di database difficile da risolvere senza tali strumenti.

A mio avviso ci sono due opzioni:

• Memorizza un numero elevato di righe uguali per gli articoli ricorrenti, tuttavia devono terminare (attraverso una data di fine o un numero finito di articoli) e devono essere contrassegnati come articoli ricorrenti. Quando si modifica l'evento, è necessario aggiornarli tutti, ma quando si desidera deviare una volta, è possibile semplicemente "interrompere" la connessione tra un evento e renderlo un evento normale.
• Memorizza l'evento come un elemento ricorrente, con un determinato schema di ripetizione, e calcola per una data determinata quali elementi ricorrenti sono dovuti in quella data. Questo dà la possibilità di una ripetizione infinita.

Se questo è un progetto personale e vuoi solo un modo per archiviare le tue attività, ti consiglio TaskCoach . È un'applicazione desktop, multipiattaforma, open source, facile da iniziare e con funzionalità davvero buone.

Nel caso in cui si stia sviluppando un'applicazione di attività, il modo più probabile è quello di aggiungere una nuova riga per ogni attività ricorrente. La logica è che ogni attività è un'entità separata in sé e deve essere completata prima che la stessa attività venga avviata il giorno successivo. Se lo incrementi, non puoi semplicemente acquisire la cronologia dell'attività.

Nel caso in cui ritieni che ti darebbe un grande elenco se alcune attività non fossero completate, potresti attivare un evento una volta completata l'attività ricorrente in modo che la nuova attività venga generata come nuova riga solo quando l'attività è contrassegnato come completato. Come suggerito da Morons, è possibile utilizzare una tabella separata con un flag per le attività ricorrenti nella tabella originale insieme ai dati per la ricorrenza (giorni, settimane, ore ricorrenti) in modo da poter disporre di un semplice script in grado di generare le attività ricorrenti in base a data o condizione o per etichetta.

Ma se sei sicuro che l'attività sia sicuramente ripetitiva senza alcuna modifica (come il pennello quotidiano) e non necessita di un monitoraggio esteso, puoi semplicemente provare la seguente struttura

• Flag di ricorrenza - per indicare che l'attività è ricorrente
• Periodo ricorrente: giorno, settimana, mese
• Numero di attività create: ciò aumenterebbe l'attività in base al periodo ricorrente. Quindi, se l'attività inizia oggi e ha un periodo ricorrente di un giorno, aumenterebbe di uno solo domani
• Numero di attività completate: aumenterebbe se l'attività viene completata

La logica è la differenza tra le attività completate e le attività create dovrebbero sempre essere il periodo ricorrente se l'attività è sempre completata. Quindi, la divisione della differenza di giorni per periodo ricorrente ti darebbe un'indicazione di quanto tempo è stato sospeso il compito.

Grazie per Kareem per averlo segnalato

IMHO, le applicazioni delle attività sono difficili da costruire per le persone in generale.

L'operazione di gran lunga più frequente sarà quella di elencare tutti gli eventi che si verificano in un periodo di tempo. Quindi ottimizza i tuoi dati in modo tale da poter rispondere a una domanda con una semplice query SQL. Vorrei creare due tabelle:

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

Indicizza la tabella degli eventi in base agli orari di inizio e fine. Quindi è possibile rispondere molto rapidamente a tutte le query dalla tabella degli eventi. Quando viene modificata una ricorrenza, è sufficiente eliminare e ricreare tutti gli eventi corrispondenti.

Questo consiglio è ripetutamente spudoratamente tratto da un libro di Tom Kite.

Le attività ripetute dovrebbero avere una data di inizio e una data di fine. Per un'attività con una sola data sarebbero la stessa data.

Crea una sorta di tabella "Date" che contiene un record per ogni giorno che ritieni rilevante dall'inizio delle tue esigenze fino al futuro che desideri: 31/12/2100 ad esempio e converti nel tuo formato.

Una query potrebbe apparire come:

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]

Ho fatto qualcosa di simile anni fa implementando un'interfaccia come l'Utilità di pianificazione di Windows e sostanzialmente per ogni attività hai StartDate, EndDate (può essere nullo), StartTime e RecurringDays che contiene giorni della settimana in cui l'attività deve essere pianificata.

È possibile utilizzare due tabelle: una per la descrizione delle attività, l'altra per il loro stato (terminata / non eseguita e altre informazioni: tempo trascorso, stato di uscita, posizione del file di registro, ecc.) La tabella di descrizione conterrebbe il il nome dell'attività e la data o la frequenza con cui deve essere eseguita: ci sarebbe una sola riga per attività. Ogni giorno, un processo popolerebbe la tabella di stato per le attività da svolgere oggi, dalla tabella di descrizione (è possibile popolare una settimana o un mese in anticipo).

Generare la tabella di stato a livello di codice ti offre tutta la flessibilità che desideri per la frequenza (ad es. "Tutti i giorni feriali tranne i giorni festivi per il paese X" - potrebbe persino essere memorizzato come una stringa). La presenza di una tabella di stato consente di verificare se o con quale frequenza le attività non riescono (ad esempio: "Avrei dovuto eseguire ogni giorno: con che frequenza ho avuto il tempo di farlo?").