Qualsiasi database ha sostanzialmente 2 tipi di tabelle: dimensioni e fatti:

1. Le dimensioni sono le tabelle di configurazione. Queste tabelle non vengono modificate frequentemente e in genere sono un singolo valore di istantanea corrente (possibilmente con alcune modifiche alla cronologia, dettagliate di seguito). Le operazioni più comuni sono le modifiche alla tabella. Si può anche pensare a questi come Config o Master.
2. I fatti sono tabelle che aumentano quasi linearmente con il tempo. In genere queste entità vengono generate regolarmente nel tempo, gli aggiornamenti ai fatti generati non sono comuni e in genere fanno riferimento a Dimensioni per un maggiore contesto.

Durante la progettazione dello schema del database, alcune delle seguenti linee guida aiutano a farlo correttamente.

Prima normale

Indipendentemente dal fatto che il database sarà SQL o NoSQL, è utile pensare alle Entità/Oggetti e quindi alle tabelle una volta da una prospettiva dello schema normalizzato. Lo schema normalizzato fornisce chiarezza su entità, relazioni e campi. La denormalizzazione o la conversione in NoSQL da questo può essere semplice e può essere un progetto consapevole.

Rispecchia entità del mondo reale

Anche se i casi d'uso/report non sono chiari, le entità dello schema dovrebbero riflettere il caso d'uso reale. Tale schema è generalmente robusto.

Uno dei seguenti è generalmente il caso per identificare e creare diverse entità e quindi tabelle:

1. Entità logicamente separate che possono esistere indipendentemente e potenzialmente senza alcun collegamento tra loro, ad esempio set di dati e stazione
2. Avere rapporti molti-a-molti o uno-a-molti tra loro, ad esempio per un'azienda di e-commerce, ordini e clienti.

Se è presente un campo utilizzato nelle query, nella ricerca o nell'ordinamento, aggiungi gli indici per impostazione predefinita. Gli indici semplici dovrebbero essere attivi per questi campi per impostazione predefinita poiché offrono il massimo vantaggio. Non aggiungere un indice dovrebbe essere una scelta consapevole, non lo stato predefinito.

Usa i tipi di campo corretti

1. Tipi di enumerazione e stringa per i campi con un set fisso di valori di opzione: le enumerazioni sono implementate come byte, quindi occupano meno spazio (ad es. 1–4 byte lungo byte/lungo/int rispetto a una stringa di 128 byte), sono più veloci/più veloci su indici e ricerche. Per i tavoli di grandi dimensioni, i requisiti di spazio e prestazioni si sommano. Utilizza le enumerazioni per impostazione predefinita.
2. Tipo di chiave primaria (ID): Prestazioni e archiviazione: è sempre consigliabile utilizzare una chiave di dimensioni fisse, ovvero numeri interi o UUID.
3. Campi comuni della tabella: alcuni campi sono suggeriti in tutte le entità ORM che possono cambiare, ad esempio created_at, updated_at, created_by, updated_by. Inoltre, per le entità che spesso possono avere collegamenti con chiavi esterne e che vengono eliminate raramente, si propone di utilizzare le eliminazioni temporanee.

La query di Drishti può essere complessa e coinvolgere più join. I database sono ottimizzati per join e calcoli in memoria. Ove possibile, esegui questi join o calcoli nel database, tramite aggiunte al livello ORM, query appropriate o riprogettazione dello schema. Come regola empirica, si dovrebbero guardare i join di risultati di grandi dimensioni nel codice dell'applicazione solo dove il database non può farlo in memoria, ad esempio per i join tra database.

Quando aggiungere le tabelle della cronologia?

Qualsiasi sistema basato sulle transazioni richiede la registrazione di base di tutte le modifiche per le entità chiave. Ciò vale in particolare per le tabelle Dimension, poiché queste vengono configurate/modificate tramite le API.

Ci sono 2 modi in cui possono essere mantenuti:

1. Mantieni un'astrazione generica per la modifica dell'attributo, in cui ogni riga in questa cronologia delle modifiche punta al tipo di entità, all'attributo, all'ID entità, al vecchio valore e al nuovo valore. Vantaggio: non richiede una nuova tabella per entità.
2. Mantieni una tabella cronologica a livello di entità per ogni modifica del valore. Vantaggio: cattura come transazioni atomiche più modifiche di campo, mostrandole come tali al cliente. Pertanto, viene preservato il concetto di transazione eseguita dall'utente sul frontend o in altro modo.