Come progettare un database con più entità correlate

Per tali scenari, è di grande aiuto se si dispone di una convenzione rigorosa per l'utilizzo di ID di attributo singolo come chiavi primarie, tutto dello stesso tipo su tutto il modello di database.

Con questa preparazione, è possibile modellare una tabella "Relazione" universale con attributi "LinkedFromTable", "LinkedFromID" e "LinkedToTable" e "LinkedToID". Gli attributi "LinkedFromTable" e "LinkedToTable" devono contenere identificatori univoci per le tabelle a cui fai riferimento (forse solo i nomi delle tabelle) e LinkedFromID e LinkedToID prendono i valori delle chiavi primarie delle righe di dati di riferimento.

L'operazione "prendi tutte le entità correlate" sarà poco costosa a causa dell'indicizzazione corretta delle colonne ID.

Ma attenzione: lo svantaggio è che perdi completamente l'integrità referenziale per queste "relazioni modellate manualmente": se elimini una riga di dati, devi controllare e aggiornare manualmente la tabella "Relazione". Per un sistema "write-once-read-many" questo può andar bene, devi decidere tu stesso.

Puoi fare quanto segue:

Avere una singola tabella di entità - Entity {id, type, ref_id_to_specific_entity_table}

Avere una tabella di relazioni singole - Relazione {id1, id2}

In questo modo è possibile ottenere tutte le entità correlate a una data entità con una singola query. Ora, se vuoi conoscere la relazione in modo specifico senza dover recuperare la seconda entità, puoi aggiungere una colonna aggiuntiva come può essere fatto con Relazione {id1, relation, id2}.

Questo significa che devi preoccuparti della coerenza se apporti delle modifiche, ma come hai detto, questo è un sistema di supporto intensivo per la lettura. Potrebbe non essere un problema.

La normalizzazione ha molti vantaggi per RDBMS, ma ha anche alcuni inconvenienti. Le prestazioni per relazioni multiple e complesse possono essere ostacolate quando si selezionano i dati.

Sembra che lo scopo principale di questa app sia fornire report e non molte modifiche ai dati da parte dell'utente tipico. Puoi mantenere la tua struttura attuale per gestire tutti i dati di ingresso / configurazione delle varie entità da parte di qualche amministratore delle informazioni, ma ciò non significa che coloro che ottengono le informazioni di aiuto debbano interrogare queste stesse esatte strutture.

A seconda di quanto sono stati modificati gli elementi della tua assistenza, puoi facilmente creare delle tabelle di segnalazione denormalizzate. Sono fondamentalmente i risultati delle query senza eseguire la stessa query più e più volte con ogni richiesta dell'utente. Ogni tipo di richiesta avrebbe una propria tabella. La tabella viene ricostruita / aggiornata / aggiornata quando vengono modificati gli articoli della guida. Dovrai codificarlo.

Esistono molti altri strumenti di memorizzazione nella cache e alcuni sono incorporati in diversi prodotti di database. Questo può diventare più costoso e complicato. Vorrei iniziare con questo. Forse puoi sceglierne uno e vedere come funziona. Indipendentemente dal fatto che la tua app stia utilizzando i risultati dell'esecuzione effettiva della query o solo una semplice query di una tabella precompilata, sta funzionando con gli stessi dati, quindi è necessario apportare poche modifiche alla tua app mentre si esegue la migrazione di sempre più di questi ad un tavolo precostruito.