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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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