Domanda di progettazione: mantieni 1000 articoli più recenti; DB vs. applicazione

Question

Domanda di progettazione: mantieni 1000 articoli più recenti; DB vs. applicazione

#1 da (1 voti)
#2 da (1 voti)

0

Ho un'applicazione Qt, che invia e riceve messaggi. I messaggi sono memorizzati in un MongoDB locale.

L'applicazione ha una finestra di elenco dei messaggi, che mostra i messaggi inviati, ricevuti e tutti (a seconda della vista). Per motivi di prestazioni, l'applicazione ha una QList, che contiene QPairs di Mongo ID e il messaggio stesso, quindi più o meno tutti i messaggi sono disponibili nell'applicazione.

Vogliamo limitare il no. dei messaggi mostrati, perché la vista diventa più lenta per 1000 e più messaggi.

L'approccio semplice era solo per limitare il no. di coppie memorizzate in QList.

Tuttavia, non ne sono sicuro, se questo è vero. Recentemente ho letto qui ( EDIT: trovato) una domanda che fondamentalmente diceva "Il tuo codice applicativo non sarà più intelligente / veloce / migliore per le cose per cui è stato progettato un DB (ad esempio, ordinamento, ottenimento di un sottoinsieme, ecc.)". Inoltre, mantenere la QList in sincronia con il DB ci causa grattacapi e alcuni casi d'angolo come un messaggio molto vecchio possono essere aggiornati e quindi devono essere nuovamente visualizzati.

Quindi la domanda è: un approccio DB-only (es. interrogare il DB per 1000 messaggi ogni volta che la vista deve essere aggiornata) essere più veloce quindi memorizzare i messaggi mostrati in modo acuto nella QList e cercare di mantenerli sincronizzati.

design mongodb qt

posta Simon 15.07.2013 - 15:54

fonte

2 risposte

Leggi altre domande sui tag design mongodb qt

Il linguaggio PHP "list ()" costruisce una cattiva convenzione? Classe di fabbrica rispetto a una classe statica

score 1 · Answer 1

Questo sembra più una separazione di preoccupazioni tra: QList, view e MongoDB.

Concentrati sullo scopo della QList e poi assicurati che le funzionalità di sincronizzazione portino a termine il lavoro. Hai bisogno di tutti i record per qualche scopo al di fuori della vista?

We want to limit the no. of shown messages, because the view gets slower for 1000 and more messages.

Se la QList per qualsiasi scopo al di fuori della visualizzazione di una vista, deve contenere più del limite di 1000 visualizzazioni, è necessario qualcos'altro per limitare i record provenienti dalla QList alla vista (se è così che serve per funzionare. ). Altrimenti, potresti aver bisogno di un'altra logica che estrae i dati MongoDB con un limite di 1000 record con il solo scopo di alimentare la vista.

La limitazione della vista (non si è sicuri esattamente di cosa si tratti) contiene abbastanza record in memoria o il controllo che si sta utilizzando come visualizzazione per l'utente (Data Grid, Combo Box, ripetitore, ecc.)?

score 1 · Answer 2

È impossibile dire se il caricamento dal database sarà più veloce senza eseguire alcuni test o sapere quanto spesso la finestra viene aggiornata. La mia ipotesi è che le prestazioni percepite che caricano o lavorano nella finestra dei messaggi diventeranno costanti anziché peggiorare con l'aumento del numero di messaggi.

Un vantaggio non trascurabile sarebbe semplificare un po 'il codice: non sarà più necessario alcun codice per mantenere l'elenco sincronizzato con il database. Ti basta prendere i messaggi più recenti (forse configurabili) quando carichi o aggiorna la finestra dei messaggi, quindi non dovrai preoccuparti di dati non aggiornati.

Come hai detto in un commento:

Let's say 300 would probably be also sufficient.

Recuperare una quantità molto piccola di dati dal database molto probabilmente non sarà notevolmente più lento, e se 300 messaggi possono coprire il 90% dei casi d'uso e puoi fornire agli utenti un modo per recuperare i messaggi più vecchi quando necessario, scommetto che Uscirò in anticipo sulle prestazioni.