Visualizza una grande quantità di dati sul client attraverso l'impaginazione

È un compromesso tra velocità, requisiti di memoria nella cache e programmazione necessaria per mantenere la cache fresca. Molto dipende dai tuoi casi d'uso. Ad esempio

• Se, come i risultati di ricerca di Google, la maggior parte degli utenti legge sempre la pagina 1, solo alcuni proseguono fino alla pagina 2 e oltre, quindi la cache potrebbe non essere nemmeno necessaria.

• Se gli utenti tendono a ordinare ripetutamente, cercare, ecc., non è possibile memorizzare nella cache le singole pagine perché il numero di combinazioni sovraccaricherà la memoria. Ma se disponi di enormi set di dati, la cache di interi gruppi di risultati farà lo stesso.

• Se i dati in background sono suscettibili di cambiare molto anche durante la lettura di una pagina, e ciò è fondamentale per l'azienda, il rischio di visualizzare dati obsoleti potrebbe trasformarti in caching.

Personalmente, potrebbe essere un investimento migliore di tempo per esaminare il refactoring del tuo database per spremere più vita da esso. Se le tue query richiedono 9 secondi, potrebbe essere dovuto al fatto che il modello di dati è troppo complesso, che manchi indici importanti o che mantieni i vecchi dati nelle tabelle principali che invece dovrebbero essere archiviati.

Puoi utilizzare l'impaginazione nella cache, ad esempio generare le prime pagine e mentre l'utente scorre le pagine, carica più pagine in background.

Questo dovrebbe darti un buon compromesso tra la velocità iniziale di risposta e il ritardo tra le pagine.

Caricare tutti i dati contemporaneamente non è necessariamente pessimo, nel senso che ha molti vantaggi in termini di prestazioni. Tuttavia, userei questo metodo solo se:

1. Ero sicuro al 100% che questo elenco non sarebbe cresciuto di grandi quantità
2. Memorizzo i dati non attualmente mostrati in oggetti javascript (in altre parole, non sovraccarichi il browser oltre alla memoria effettiva necessaria per tenerlo).

Il più delle volte, non posso garantire che l'elenco non cresca, quindi di solito devo attenermi alla seconda soluzione che hai menzionato. Carica per pagina su richiesta. Ciò significa anche che non è possibile effettuare la ricerca utilizzando gli elementi disponibili a meno che la ricerca di elementi nella pagina corrente sia accettabile. La ricerca deve eseguire la sua query sul database separata dalla cache che hai.

Non mi preoccuperei di memorizzare nella cache le pagine che hai già caricato, dal momento che ogni quanto ritorni alle pagine precedenti dopo averle viste? Non vale la perdita della memoria a mio modesto parere. Piuttosto, ti consiglierei di caricare più pagine contemporaneamente anziché solo una alla volta. Quando l'utente fa clic su Avanti e non viene caricato nulla, si recuperano le 4 pagine successive. In questo modo, nulla deve essere recuperato per il seguente 3. Questa è già una soluzione che soddisferà la maggior parte dei tuoi requisiti e sarà comunque 4 volte più efficiente di scaricare una pagina alla volta.

Se vuoi diventare ancora più sofisticato, useresti AJAX per caricare la pagina successiva una volta che l'utente ha caricato la pagina corrente. Devi solo controllare che la pagina successiva sia già stata caricata prima di mostrare la pagina successiva, il che, spero, sarà sufficiente per il tempo che sarà già stato caricato. E nel caso in cui non è stato ancora caricato, è possibile mostrare una sorta di animazione di caricamento per fornire un feedback all'utente che si sta attualmente lavorando su di esso. Questo ha le migliori prestazioni di tutte le soluzioni, tuttavia è anche la più difficile da implementare.

Spero che ti aiuti!

In genere preferisco la soluzione numero 2, per quanto riguarda l'approccio misto

Domande cercapersone:
Utilizzare una query paginata quando si mostra un elenco di dati all'utente finale è il modo normale.
Seguendo l'approccio della creazione di query pagate con il modello di query seguente:

SELECT TOP pageSize columns  
  FROM Table    
  WHERE IDColumn NOT IN ( SELECT TOP pageSize*(pageNumber-1) IDColumn    
  FROM Table    
  ORDER BY uniqueOrPrimaryKey)    
  ORDER BY uniqueOrPrimaryKey;

I punti chiave saranno:

• Progettare efficienti oggetti Data Transfer-er.
• Scegliere page size efficace, in base all'entità dimensione, limitazione della larghezza di banda, nessun test funzionale ...
  

Informazioni sull'incasso: L'utilizzo della strategia di incassamento dipende dalle specifiche e dalla logica aziendale dell'applicazione.
Alcuni dati possono essere incassati e incassare alcuni dati causeranno l'incoerenza del caso.

Pensa a un software di Internet Banking, in cui l'utente vedrà i suoi account elencati dati, sarà un buon approccio per incassare i dati degli account quando l'utente sta effettuando l'accesso (poiché la creazione dell'account non viene normalmente eseguita dall'applicazione di banca internet).
Ora l'utente può eseguire alcune azioni di addebito e credito e il saldo dei suoi account verrà modificato, dobbiamo aggiornare il campo del saldo e aggiornare il denaro.

In ogni caso, l'utilizzo di dati incassati ti porrà di fronte domande di progettazione di applicazioni come quando cancellare o aggiornare i dati incassati, utilizzando l'incasso lato client o lato server, la sicurezza dei dati per l'incasso del lato client, ecc.

Conclusione
Userò il paging quando mai possibile, che ottimizzerà le prestazioni.
Userà incassare dati statici che sono meno aggiornabili.
Non userà incassare dati e scenari concorrenti.
Caveat- > Non tenterà di alterare la natura stateless del protocollo HTTP incassando.

Puoi avere un approccio combinato prendendo il meglio da entrambi i mondi.

Come? - >

Poche settimane fa mi sono imbattuto in una libreria - oboe.js che carica i dati in streaming dando oggetti analizzati prima la risposta è completa.

Quindi, anziché aspettare 9 secondi per caricare i dati, è possibile eseguirne il flusso e utilizzare gli oggetti analizzati non appena sono disponibili. In questo modo, sarai in grado di caricare tutti i dati e anche di non dover aspettare a lungo.