È una pratica scorretta aggregare i dati di diverse tabelle in una sola?

sfondo

Scrivo molti report di grandi dimensioni e in genere conservo un database di record sanitari di grandi dimensioni (scrivere SP, funzioni, lavori, ecc.). Lo schema originale e il software che lo utilizza provengono da un fornitore diverso, quindi non posso cambiare molto strutturalmente. Ci sono molti documenti che richiedono il monitoraggio come laboratori, procedure, vaccini, ecc. E sono sparsi su dozzine di tavoli, molti dei quali sono gonfiati e scarsamente indicizzati (sono stato in grado di risolvere un po ').

Il problema

Il problema è che, poiché abbiamo scarso controllo sul DB e poiché può cambiare da qualsiasi dato aggiornamento o patch, rende difficile e noiosa la scrittura e la gestione di questi report, soprattutto in presenza di grandi sovrapposizioni. Basta una sola patch e sono bloccato a riscrivere gran parte di una dozzina di rapporti. Inoltre, le query diventano rapidamente offuscate e lente man mano che i join, il nidificato vengono selezionati e applicati si accumulano.

La mia "soluzione"

Il mio piano era di scrivere tutti questi record in una tabella "catch-all" e scrivere trigger sulle tabelle originali per mantenere i record in questa tabella aggregata. Ovviamente avrei bisogno di assicurarmi che i miei trigger fossero intatti dopo gli aggiornamenti, ma questo sarebbe molto più facile dal punto di vista della manutenibilità e facendo semplicemente riferimento ai dati.

La tabella sarebbe sottile e lunga, memorizzando solo i dati richiesti, qualcosa del genere:

CREATE TABLE dbo.HCM_Event_Log (
    id INT IDENTITY,
    type_id INT NULL,
    orig_id VARCHAR(36) NULL,
    patient_id UNIQUEIDENTIFIER NOT NULL,
    visit_id UNIQUEIDENTIFIER NULL,
    lookup_id VARCHAR(50) NULL,
    status VARCHAR(15) NULL,
    ordered_datetime DATETIME NULL,
    completed_datetime DATETIME NULL,
    CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id)
)

Quindi avrei varie tabelle relazionali per cose come type_id e raggruppamenti di elementi.

Sto iniziando a indovinare questa idea dato che molte di queste tabelle sono state scritte un po ', gli SP e i rapporti che scrivo farebbero riferimento anche ai dati. Quindi sono preoccupato che questa tabella diventi un incubo per il blocco dei record e delle prestazioni con così tanti I / O.

La mia domanda

È una cattiva o una buona idea? Mi rendo conto che ogni situazione è diversa in SQL Server (2008 r2 Standard Edition BTW) e nella regola "a volte", ma sto davvero cercando consigli generali.

Ho iniziato a considerare l'utilizzo di un broker di servizi, ma eseguivo solo semplici aggiornamenti / inserimenti ( vedi l'alternativa alla risposta accettata ). In molti casi i dati devono essere in tempo reale, quindi l'utilizzo di un DB di backup non funzionerebbe davvero. Le prestazioni sono già un po 'un problema per noi, ma la maggior parte è legata all'hardware che verrà risolta presto.

Se ti capissi correttamente,

• hai un grande sistema di terze parti,
• non hai molto controllo su di esso,
• fai report complessi che leggono i dati direttamente da questo database di terze parti,
• le tue query dipendono dalla struttura interna del database di terze parti.

Mi avvicinerei così:

• Imposta il mio database separato, di cui ho il pieno controllo.
• Imposta un processo di sincronizzazione che legge i dati da tabelle e colonne pertinenti dal database di terze parti e inserisce / aggiorna nei miei.
• Sviluppa i miei report complessi basati sulla struttura stabile del mio database.

In questo caso è possibile ottimizzare la struttura e gli indici del database per migliorare le prestazioni dei report, senza influire sul sistema di terze parti. A meno che la struttura dei dati originale non cambi radicalmente, la logica delle query per i report non cambierebbe se cambiassero database di terze parti. Dovresti modificare solo il processo di sincronizzazione.

Il processo di sincronizzazione è effettivamente il processo di conversione : converti i dati da database di terze parti nella struttura di cui hai bisogno. Parte di questo processo di conversione potrebbe essere risolvere eventuali problemi di normalizzazione che potrebbe avere il database di terze parti originale. Solo questa parte del sistema deve conoscere e dipendere dalla struttura interna del sistema di terze parti. I report principali e le query principali dipenderanno solo dal database.

Quindi, il punto principale è: separare e limitare la parte del sistema che dipende dagli interni del sistema di terze parti.

aggiornare

Per quanto riguarda i requisiti in tempo reale. A proposito, ho sempre pensato che la definizione di "tempo reale" sia "tempo di risposta garantito", non "tempo di risposta ridotto". Dipende dalla tua applicazione, ovviamente. Nella mia pratica è sufficiente sincronizzare due database entro un minuto dalla modifica rilevata. Se un utente visualizza un report sullo schermo e alcune modifiche ai dati sottostanti, il report deve essere in qualche modo rieseguito per riflettere questa modifica. È possibile eseguire il polling per le modifiche o ascoltare alcuni eventi / messaggi, tuttavia la query del report deve essere nuovamente eseguita per mostrare le ultime modifiche.

Hai già intenzione di scrivere trigger per acquisire le modifiche nelle tabelle originali e scrivere queste modifiche in una tabella generica. Quindi, acquisisci le modifiche come previsto, ma scrivile su tabelle correttamente normalizzate, non una sola.

Quindi, questo è un caso estremo: la conversione della struttura di dati di terze parti nella struttura di dati interna viene eseguita nei trigger che si attivano su INSERT/UPDATE/DELETEtabelle di terze parti. Può essere complicato. Il codice dei trigger dipende dalla struttura interna di entrambi i sistemi. Se la conversione non è banale, può ritardare l'originale INSERT/UPDATE/DELETEal punto del loro fallimento. Se è presente un bug nel trigger, potrebbe influire sulla transazione originale fino al punto del loro errore. Se il sistema di terze parti cambia, potrebbe interrompere il trigger, causando il fallimento delle transazioni del sistema di terze parti.

Caso meno estremo. Per rendere il codice dei trigger più semplice e meno soggetto a errori, scrivere tutte le modifiche acquisite su alcune tabelle di staging / audit / diff, impostare alcuni flag / inviare un messaggio in attesa di modifiche e avviare il processo di conversione principale che andrebbe attraverso queste tabelle intermedie ed eseguire la conversione. La cosa principale qui è che il processo di conversione potenzialmente pesante dovrebbe avvenire al di fuori dell'ambito della transazione originale.

A una seconda occhiata assomiglia più o meno al tuo suggerimento originale nella domanda. Ma la differenza è: le tabelle di acquisizione di tutti contengono dati solo temporaneamente; la quantità di dati è piccola, proprio ciò che è cambiato; non deve essere un unico tavolo; alla fine i dati verranno archiviati in tabelle permanenti separate, opportunamente normalizzate, di cui hai il pieno controllo, che sono indipendenti dal sistema di terze parti e che puoi sintonizzare per le tue query.

Inseriscilo in una serie standardizzata di tabelle in modo da poter modificare la fase di importazione anziché dover modificare report e query complessi. Ma i dati dovrebbero comunque essere normalizzati, il che richiederà tabelle multiple (ma con buoni indici).

Come altri hanno già detto, non usare i trigger, sincronizza in batch.

Non preoccuparti di molti join, quando i dati vengono normalizzati e indicizzati correttamente, questi non comportano costi significativi o oneri di gestione.

Il tempo di denormalizzare in qualcosa di simile a un data warehouse è quando è necessario essere in grado di eseguire molti tipi diversi di query sui dati che non è possibile prevedere. Ha i suoi svantaggi e costi generali e dovrebbe essere usato dove appropriato, non come cosa da fare.

Ho lavorato con una situazione molto simile come questa in passato in un'azienda manifatturiera 24x7 e alla fine ho deciso di utilizzare la replica transazionale. È possibile configurare DDL in modo che venga replicato in modo tale da poter inviare qualsiasi abbonamento al sottoscrittore. Ovviamente ci sono pro e contro in tutto e devi valutarli per determinare cosa puoi supportare rispetto a ciò che funziona meglio per l'azienda.

Sul lato positivo:

1. "Tempo reale" è limitato solo alle prestazioni di commit della rete e delle transazioni sull'abbonato. Nella mia esperienza con un sistema TPS moderatamente alto, siamo stati replicati in meno di 10 secondi di dati "in tempo reale".
2. Separazione dei carichi di lavoro. Attualmente stai eseguendo un carico di lavoro misto su un server. Se riesci a separare queste due preoccupazioni, potresti essere in grado di ottenere i vantaggi in termini di prestazioni su entrambi i sistemi di aver rimosso un carico di lavoro dall'equazione
3. Controllo. Sarai in grado di apportare modifiche all'indicizzazione / statistiche / manutenzione in base al carico di lavoro dei rapporti.

Ci sono contro, tuttavia:

1. Costo. Un'altra licenza e altro hardware (virtuale o di altro tipo).
2. Replica. Funziona alla grande una volta che è stato impostato correttamente, ma può essere una seccatura arrivare a quel punto.
3. Manutenzione. Se si apportano modifiche deleterie alle strutture (ad es. Rilasciare un indice), verranno restituite quando viene applicata l'istantanea (dopo che la pubblicazione è stata modificata o quando gli articoli sono cambiati).

Il mio piano era di scrivere tutti questi record in una tabella "catch-all" e scrivere trigger sulle tabelle originali per mantenere i record in questa tabella aggregata.

I trigger hanno così tanti problemi che dovresti evitarli:

• Un errore in un trigger può causare l'interruzione della transazione originale
• I trigger che gestiscono correttamente le operazioni multi-riga sono difficili da scrivere
• I trigger possono confondere le applicazioni client modificando il set di righe restituito (ad esempio, un trigger sostituisce il numero di righe interessate)
• Quando un trigger ne attiva un altro, i risultati sono difficili da prevedere

Un'opzione migliore è un lavoro che copia periodicamente i dati in una nuova tabella. I rapporti possono essere eseguiti della copia. Un lavoro che copia le righe è facile da scrivere e gestire e non vi è alcun rischio che influisca sul funzionamento dell'applicazione di terze parti.