Un file XML o un database?

Se ho capito bene, i tuoi dati cambiano una volta al giorno. Per essere onesti, non importa se lo si possiede come XML, o lo memorizza fila per fila in un DB; ciò che farebbe una grande differenza è memorizzarlo nella cache nella tua applicazione web.

In pratica, dovresti leggere il file al massimo una volta al giorno (questo può succedere su richiesta, basta controllare se la versione cache è scaduta) e archiviare il suo contenuto in una struttura ottimizzata per il recupero rapido delle informazioni. Ciò impedirà alle tue pagine di sprecare tempo CPU analizzando il file più e più volte, oltre a salvare il garbage collector molto lavoro.

Tecnicamente, un file XML da 10 MB dovrebbe occupare una quantità di memoria simile a quella degli oggetti (tenendo conto della mancanza di ingombro di una codifica basata su testo, ma anche per il sovraccarico di avere oggetti Dizionario per l'indicizzazione), che non è nulla questi giorni. Cambiamenti come questi di solito provocano un aumento delle prestazioni di un paio di ordini di grandezza.

In parte sto riecheggiando ciò che ha già detto jberger, sembra che tu ti abbia già parlato di farlo.

Sarei favorevole al passaggio a un database, dodici megs sono un file piuttosto grande. Come una serie di tabelle potresti sfruttare parte della potenza di un database per velocizzare le query, magari fare cose nuove che hai trovato noiose o laboriose prima. Anche in questo caso altri posters hanno chiesto quanto spesso stai interrogando questo file. Se è una volta al giorno forse forse, solo forse, potrebbe non valerne la pena. Tuttavia, se è un po 'complesso di XML e 12 MB dicono che lo è, potresti scoprire che il tempo è ben speso.

Non sto ignorando l'idea di utilizzare i file XML come archivi dati, li ho usati in passato sui siti Web, ma le loro dimensioni e il traffico su quei siti Web ne valeva la pena. I siti Web non ricevono molti visitatori al mese e le dimensioni dei file XML utilizzati sono misurate in KB.

Ho riletto di nuovo la tua domanda e ho avuto un'altra idea. Al momento stai facendo tutto il lavoro sul web-server. Se si utilizza un server di database, SQL Server memorizza nella cache i piani di esecuzione. Il mio istinto è che usando un server di database userete le risorse in modo più efficiente. Con i database è possibile aggiungere indici alle tabelle che possono migliorare notevolmente le prestazioni.

Se parli di costi e risorse, il consumo di un servizio Web è più costoso rispetto al recupero dei dati da un database ospitato sul server o locale.

Nello scenario, è inoltre necessario tenere presente che i dati vengono aggiornati tramite dati file XML o meno. Se lo fa, controlla anche quando ciò accade? In quale periodo di tempo è necessario recuperare i dati da XML (ad esempio ogni 5 minuti, 10 minuti, 1 ora, 1 anno)?

La lettura di un file XML di quelle dimensioni ogni volta che viene caricata la pagina web può diventare naturalmente un collo di bottiglia per le prestazioni. Memorizzando il file in una variabile di sessione di tipo XmlDocument (vedi link ) si riduce a "un carico" per sessione utente ", che potrebbe essere molto più veloce. L'utilizzo della sintassi della query xpath / xslt offre una flessibilità paragonabile a SQL.

L'utilizzo di un database come cache ha senso solo se il tempo di vita del processo del database è più lungo della durata del processo della pagina Web ASP.NET, quindi non è possibile utilizzare un database in memoria come SQL Server Compact Edition. Ciò significa che avrai una comunicazione tra processi tra il processo della tua pagina web e il processo del tuo database, che è il principale rischio di prestazioni di quella soluzione. La query su un XMLDocument caricato viene eseguita completamente in-process. Quindi, se paga davvero usando un database, lo saprai solo se lo testerai, ed è assolutamente possibile che la soluzione del database sia molto più lenta della soluzione XML memorizzata nella cache. Ovviamente, se la quantità di dati aumenta fino a diverse centinaia di MB o più, allora ci sarà un punto in cui una soluzione che non carichi tutti i dati disponibili sarà più veloce.

Dichiarazione di non responsabilità: non ho mai programmato un sito ASP.NET da solo, quindi scusami se ho frainteso qualcosa di quell'architettura.