Показать большой набор результатов

Question

Это моя проблема: мне нужно хранить много сообщений журнала, и я подумал, что было бы разумно сохранить его в базе данных SQLite3, чтобы можно было легко искать и фильтровать его.

Я буду отображать сообщения журнала в стандартном виджете списка (используя wxWidgets). Список будет иметь несколько столбцов и может быть отсортирован и отфильтрован пользователем.

Теперь я не уверен, что это лучший способ справиться с этим. Я думаю о некоторых возможных решениях:

<Ол>

Читать все сообщения в память. Когда появляется новое или измененное сообщение журнала (в произвольной позиции в списке), весь список должен быть обновлен. То же самое, когда пользователь хочет отфильтровать список или отсортировать по другому столбцу.

Считывание всех идентификаторов в массив и получение полного сообщения журнала по требованию (когда пользователь прокручивает список, чтобы они были видны).

Используйте SQL-интерфейс для извлечения результатов по запросу, используя SQL, чтобы выбрать точный вспомогательный результат, который требуется.

Но на самом деле, я просто не привык работать с такой проблемой, поэтому любые советы приветствуются!

Answer 1

Как насчет использования нумерации страниц?

SELECT *
FROM logs
WHERE ...
ORDER BY ...
LIMIT offset, count

Где смещение и число - это значения, которые вы можете выбрать. Вы можете использовать это, чтобы получить любое количество записей журнала. Затем добавьте следующую кнопку, чтобы позволить пользователю просматривать следующую страницу записей. В сочетании с возможностью фильтрации и сортировки поиск по журналу не может быть проще.

Answer 2

Начал писать это как комментарий к ответу Нади, но я начал бродить, и это стало слишком длинным :)

Имейте в виду, что, поскольку количество записей журнала становится очень большим, полоса прокрутки становится бесполезной. Самое крошечное движение в свитке заканчивается резким перемещением по списку. Это делает нецелесообразным использование пользователем поиска в списке.

Подумайте, почему пользователи будут на самом деле просматривать эти записи и разрабатывать вокруг них. С очень большими списками не просто сложно работать в коде, но и с пользователями. Я бы, наверное, дал им несколько критериев фильтрации и постраничных результатов.