I have a Qt application, which sends and receives messages. Messages are stored in a local MongoDB.The application has a message list window, which shows sent, received and all messages (depending on the view). For performance reasons the application has a QList, which holds QPairs of Mongo ID and the message itself, so more or less all messages are available in the application.We want to limit the no. of shown messages, because the view gets slower for 1000 and more messages.The simple approach was just to limit the no. of pairs stored in the QList.However, I'm not quite sure, if this is true. Recently I've read here (EDIT: found it) a question which basically said Your application code won't be smarter/faster/better for stuff a DB is designed for (e.g. sorting, getting a subset, etc.). In addition keeping the QList in sync with the DB is causing us headaches and we have some corner cases like an very old message can be updated and then has to be displayed again.So the question is, would a DB-only approach (e.g. querying the DB for 1000 messages whenever the view has to be updated) be faster then storing the acutally shown messages in the QList and trying to keep them in sync.
Design Question: Keep 1000 newest items; DB vs. application
design;qt;mongodb