Fabriziog ha scritto:
Premessa: tutti i software che registrano le attività sportive registrano solo le uscite.
Questo credo sia ovvio: in genere, sono quelle le attività che si vogliono tracciare.
E' come avere un registro degli eventi e salvare al suo interno "quando non succede nulla": sarebbe un agglomerato enorme di dati, di cui sarebbe difficile definire una granularità ideale, che fornirebbero informazioni sostanzialmente inutili, poiché a tutti interessa avere evidenza di qualcosa che succede, non di qualcosa che non succede.
Diverso è invece dire "avrebbe dovuto succedere", poiché in quel caso si registra il fallimento di un evento che avrebbe dovuto avere luogo, che è un esempio che si può utilizzare anche nel tuo caso.
Fabriziog ha scritto:
Io registro anche quando non esco. In questo modo in ogni momento so quanti giorni ho saltato e perché.
Mi sembra limitativo. Se si presuppone che si esca una volta al giorno, ti basta scandire le attività effettivamente eseguite per conoscere in pochissimi istanti quanti giorni hai saltato, senza andare singolarmente a salvarti per ogni giorno il fatto che non hai eseguito l'attività.
E' più corretto non salvare questa impostazione: in questo modo, se cambi al volo la frequenza passando da una attività al giorno a due attività, ottieni in un secondo il calcolo aggiornato, che non sarebbe invece possibile se tu ti basassi solo sui record che hai inserito.
Fabriziog ha scritto:
Detto ciò, finora ho sempre pensato che il punto di partenza del database fosse la registrazione di un'attività.
E fin qui non ci vedrei nulla di male, anzi direi che è un buon punto di partenza: la fattorizzazione deve seguire dopo quando vedi che, aggiungendo informazioni o tipologiche, è necessario normalizzare la base dati perché ti rendi conto che stai ridondando troppi dati (es. ripetendo più volte un campo "Tipo attività" che potrebbe essere censito in un'altra tabella e collegato alla tabella principale delle "Attività" tramite un ID).
Fabriziog ha scritto:
Partendo da qui ho sempre pensato che la tabella da cui partire fosse quella in cui bisognasse inserire una data. Tabella a cui collegare le altre tramite relazioni e per non creare un elenco del telefono tipo Excel fosse necessario suddividere le informazioni a seconda che registrassi un'uscita, registrassi una mancata uscita e così via.
Questa commistione di riflessioni su ciò che devi memorizzare in generale e come i dati sono strutturati va eliminata: sono due contesti completamente separati, poiché il salvataggio di una attività con tutti i suoi dati annessi è l'inserimento di uno o più record aggregati che vanno distribuiti sulla base dati per evitare ridondanza.
La base dati non cambia in base al punto di partenza o in base a ciò che consideri "principale" o "secondario", ma dipende solo da quali e quanti dati salvi, quanto vengono ripetuti (da cui si rende necessaria una normalizzazione) e dalle relazioni che esistono tra gli stessi (se stiamo parlando di RDBMS).
Fabriziog ha scritto:
Guardando meglio mi è venuto il dubbio che questo mio modo di ragionare risultasse complicato.
Cosa c'entra il modo di ragionare? La base dati va progettata per bilanciare il recupero ottimale delle informazioni che servono al software evitando il più possibile ridondanza dei dati (o permetterla dove serve per questioni di performance).
La complessità del ragionamento non c'entra nulla.
Fabriziog ha scritto:
Forse, anziché partire dalla registrazione che metteva al centro la data, potevo far partire il database dalle categorie delle registrazioni.
Come predetto, non c'è un "mettere al centro" né un inizio o una fine.
Banalmente, il discorso da fare è questo: se le attività che fai possono appartenere a diverse categorie, e ha senso distinguerle, avrai una tabella "Categorie" che le elenca tutte, ciascuna con un proprio ID identificativo, e nella tabella "Attività" avrai un campo "CategoriaID" che referenzia la categoria a cui appartiene quella attività, in modo da evitare ridondanza di dati (la ripetizione delle informazioni sulle categorie, come la descrizione) e l'eventuale possibilità di scegliere in seguito una categoria per filtrare tutte le attività che appartengono a quel tipo.
Fabriziog ha scritto:
Un po' come avviene nei gestionali (le fatture hanno un loro percorso, i DDT un altro, gli ordini un altro ancora...).
Sbagli. Molti gestionali hanno una tabella unica per tutti i documenti, e una tabella per le righe dei documenti, a prescindere dalla loro tipologia, e tutt'al più possiedono un campo sulla tabella principale dei documenti che definisce la tipologia di appartenenza dello stesso documento (es. DDT, fattura, ordine, ecc.) che potrebbe essere un tipo descrittivo composto da un codice (es. DT, FT, OR) o da un ID di una tabella tipologica correlata.
In genere è così, a prescindere dalla tipologia, perché spesso i documenti hanno caratteristiche in comune ed è inoltre più facile in questo modo generare l'uno a partire dall'altro, copiando banalmente i dati del record di testata e dei record delle relative righe.
Fabriziog ha scritto:
E la data, anziché essere unica, essere replicata in ogni tabella relativa al tipo di registrazione da effettuare.
Non ne vedo il motivo pratico.
Fabriziog ha scritto:
E la categorizzazione delle attività venisse subito dopo (non so se riesco a spiegarmi) [...]
Direi di no, perché secondo me c'è molta confusione riguardo a cosa si intende per "normalizzazione di un DB".
Prima di procedere, darei uno sguardo alle risorse che ti sono state suggerite per approfondire questo argomento perché avviare un progetto basato su una struttura dati non ottimizzata o difficile da manutenere costituisce un ostacolo al buon fine di qualsiasi implementazione.
Ciao!