Metodologia dietro il recupero di grandi insiemi di dati XML in pezzi

Decidi il numero massimo di pagine che il tuo utente dovrebbe esplorare in 1 sessione. Effettua un recupero del client che ottiene un set di chiavi primarie che soddisfano i tuoi criteri massimi e restituiscono questo set al tuo cliente. Questo processo viene eseguito solo 1 volta. Ogni volta che l'utente richiede la pagina successiva o precedente, utilizzare il set di chiavi incassato per ottenere le righe desiderate in base alle dimensioni della pagina. Questo metodo recupera sempre al massimo n righe in cui n è il numero di righe nella pagina (dopo il recupero di denaro iniziale). Quando l'utente ha terminato, svuota le chiavi in contanti. Questo metodo è particolarmente utile quando si dispone di una query complessa in cui un semplice SQL come "SELECT * FROM ... Where Key > lastKey" non funzionerà. Gli svantaggi di questo approccio sono:

1 - Questo metodo ignora i record nuovi e rimossi dopo che l'utente ha richiesto la richiesta di esplorazione iniziale, tuttavia, questo è generalmente accettabile in molti tipi di applicazioni LOB.

2 - Questo metodo richiede il recupero delle chiavi in anticipo, tuttavia, se il tuo numero max. il numero di pagine è ragionevole, questo non dovrebbe essere un problema, specialmente quando la query è ben qualificata.

La soluzione dipende da dove si trova il problema.

• Se il problema è nel tempo necessario per generare il lato server XML, puoi prendere in considerazione l'ipotesi di ottimizzarlo. In particolare, cerca un approccio alternativo che non implichi la creazione di un DOM in memoria e la serializzazione. (Non ho familiarità con Delphi).

• Se il problema è nel recupero dei dati dal database, l'ottimizzazione delle query può essere di aiuto.

• Se il problema è nel tempo necessario per trasmettere i dati, considera di inviare meno; per esempio. lascia fuori cose che non verranno mostrate immediatamente. È possibile farlo escludendo i campi (che possono essere recuperati in un secondo momento, se necessario) o "impaginando" il set di dati. Sfortunatamente, entrambi comportano modifiche sul lato client e modifiche sul lato server.

Se lo ridimensiona, il paging è l'unica soluzione che può potenzialmente ridimensionare indefinitamente.

Un approccio completamente diverso è elaborare il set di dati di grandi dimensioni sul lato server e inviare solo un sommario ...

I'm going to implement session management, where I can keep a dataset open for a period of time until idle time expires. During that time, the client can fetch chunks of the results at a time.

Devi stare attento con questo. Esiste un potenziale di negazione accidentale o intenzionale dei problemi del servizio se i client aprono molti set di dati e consentono loro di scadere:

• Il timeout dovrebbe essere breve e basato sul tempo trascorso dall'ultimo utilizzo dell'impostazione del set di dati, piuttosto che dall'ora in cui è stato aperto.

• Considera un'implementazione che non richiede una transazione a esecuzione prolungata per ogni handle del set di dati; per esempio. utilizzare un identificatore specifico dello schema che consente di chiudere un set di risultati del database e quindi di inviare una nuova query per riprendere l'iterazione.

Durante la discussione del concetto di Session Management, ho deciso che andrò avanti e lo implementerò. Ogni sessione avrà un solo set di dati, aggiornato su richiesta, in cui il client può recuperarne pezzi alla volta. Sono fiducioso che non avrò sessioni eccessive e quindi capisco come implementarlo tramite le sessioni. La struttura è più che spiegata nella domanda e ho concluso che una chiave API dovrebbe attivare un altro livello di autenticazione: Sessioni / cookie. Ogni sessione ha il proprio set di dati.