È accettabile modellare un grafo di oggetti molto complesso usando XML nel database, ma lasciare il resto di un sistema in tabelle relazionali?
Mi piacerebbe valutare l'opinione su questo perché ho trovato un po 'di enigma.
Grazie mille
--------------------
Sfondo
Sto costruendo un'applicazione finanziaria che, sebbene non sia affatto grande in termini di memorizzazione dei dati (< = decine di megabyte inizialmente), avrà un modello di dati molto complesso.
In particolare, gli utenti lavoreranno nel contesto di un'entità "Progetto", che conterrà varie sotto-entità ed elenchi. Gli utenti saranno in grado di aggiungere formule a diverse parti di questo oggetto grafico e saranno continuamente ricalcolate in tempo reale.
La complessità arriva in due parti:
-
Indipendentemente da dove si trova una formula nella gerarchia di classi, sarà in grado di raggiungere qualsiasi altra parte della stessa entità di progetto principale utilizzando una sintassi simile a un percorso. Ciò includerà i risultati di altre formule e implementerò tutto questo con una struttura di dipendenze in memoria su un livello intermedio.
-
Vorrei che tutte le formule avessero la stessa struttura di base, i metadati, ecc. Per fare ciò, tutte le formule saranno rappresentate dalla stessa struttura di classe nel codice, indipendentemente da quale parte del grafico dei dati esse sono allegati a
Preferirei avere tutto il resto in un documento - significherebbe molto meno tempo dedicato alla progettazione del database, e sarei in grado di avere un modello di oggetti molto più ricco per lo stesso sforzo. Sono preoccupato per l'integrità relazionale - vorrei comunque memorizzare i miei dati statici nelle tabelle relazionali.
Tecnologie
- SQL Server 2012.
- .Net 4.5 (via C #)
- Entity Framework (primo database) sul livello intermedio
- Semplici DTO generati automaticamente su WCF per i servizi
- WPF con Prism sul client.
Non ho considerato le idee di archiviazione NoSQL, in gran parte perché non ne ho abbastanza esperienza per un progetto con scadenze ristrette. Inoltre, non ho considerato il codice Entity Framework per la stessa ragione.