Miglior approccio per archiviare enormi quantità di dati denormalizzati / dinamici con database relazionale

2

Qui ho un ILS (Integrated Library System) molto semplice fatto molto tempo fa (realizzato con C # / SQL Server), in produzione da anni. Ma ora ho una richiesta di rendere questo sistema conforme allo standard MARC 21, e con questa domanda è venuto il dubbio: Poiché questo standard ha molti tipi di registro, e ogni tipo di registro può avere molti campi opzionali / variabili in base al tipo di pubblicazione (libri, note musicali, periodici, ecc.), come potrei progettare questo?

La mia prima idea era di avere alcune tabelle di "metadati". Queste tabelle conterranno tipi di registro, con un'altra tabella ternaria con tutti i registri possibili per ogni tipo di pubblicazione, secondo i documenti . Queste tabelle si uniranno con un'altra tabella contenente tutti i possibili sottocampi per ogni registro, e con un'altra per tutti i possibili valori per ogni sottocampo "tipo fisso" ... Un sacco di join che conosco, ma MARC 21 ha un sacco di cose con tipi fissi o valori predefiniti.

I dati di pubblicazione reali (con tutti i campi variabili) ho pensato che potevo memorizzare in una tabella valori-chiave (denormalizzata, dove una chiave è un valore composto con <Publication-Id><Register-code><Subfield-Id> ) o in una tabella enorme con tutto il registro possibile e tutti i campi possibili, in cui ogni colonna potrebbe essere denominata Reg<register-code>_<register-field> .

So che potrei prendere il "percorso NoSql" e "cantare insieme" con tutti i miei dati dinamici, ma dovrò abbinare questa struttura con un db SQL Server esistente.

Ho già alcune tabelle normalizzate (es .: autori, tipi di pubblicazioni e così via)

Come dovrei progettare questo?

    
posta cezarlamann 23.05.2016 - 23:29
fonte

1 risposta

1

Mi chiedo se quello che stai cercando di fare in realtà renderà le cose estremamente difficili. In particolare ciò che dici sull'accoppiamento dei dati a un DB del server SQL esistente.

Questo mi fa pensare che vogliate eseguire in modo efficace due database. Anche se fattibile, i problemi relativi a query, sincronizzazione e prestazioni risulteranno in grandi quantità di codice, bug e altri mal di testa.

Quale potrebbe essere una soluzione migliore sarebbe considerare il DB del server SQL e una fonte di dati legacy che è necessario importare nel nuovo database come parte della produzione. Quindi avere un singolo database semplificherà enormemente ciò che stai facendo. E la semplicità è la chiave di tutto questo.

Seguendo questo approccio puoi tranquillamente considerare NoSQL o qualche altro motore che soddisferà al meglio i tuoi scopi. L'unica complessità sono i filtri di importazione che dovrai scrivere per leggere i soli dati, formattarli e memorizzarli nel nuovo database.

    
risposta data 24.05.2016 - 05:47
fonte

Leggi altre domande sui tag