Vedo due scelte per tenere traccia dei tipi:
-
Memorizza il tipo esplicitamente in ogni attività e aggiungi vincoli al database per verificare che tutte le attività figlio abbiano un tipo compatibile. Se disponibili, i tipi di enumerazione sarebbero appropriati.
-
Lascia che il tipo sia implicito nella tabella / collezione che contiene queste attività. Per esempio. potresti avere una tabella degli obiettivi e una tabella di routine, non una singola tabella delle attività.
Per implementare la struttura ad albero, l'approccio relazionale puro dovrebbe avere in ogni bambino un riferimento all'attività genitore. Per le attività di root questo riferimento sarà nullo.
CREATE TABLE IF NOT EXISTS tasks (
id INT PRIMARY KEY,
parent REFERENCES tasks(id)
);
Funziona ma non è molto comodo da usare - per recuperare tutti i sottoattività hai bisogno di una query ricorsiva. Il tuo DB potrebbe avere estensioni per query gerarchiche.
Anche ordinare non è banale. L'attività potrebbe avere una colonna order che supporta i numeri decimali. Per inserire un'attività tra due attività esistenti, l'ordine medio dei vicini è medio. Dopo un certo numero di inserimenti potresti incorrere in problemi di accuratezza numerica e dovrai ricalcolare l'ordine. Ancora una volta, il database potrebbe avere estensioni per semplificare questo.
Alcuni database (in particolare i database dei documenti) consentono di mantenere semplicemente un elenco di ID attività figlio, che semplifica l'ordine e le richieste figlio. Tuttavia, ciò potrebbe rendere impossibile o almeno più difficile l'applicazione dei vincoli di chiave esterna. Per esempio. PostgreSQL supporta colonne di array, ma AFAIK devi controllare manualmente il vincolo di chiave esterna.