Правильная реализация шаблона проектирования фильтра (критериев)
Шаблон дизайна объясняется здесь:
http://www.tutorialspoint.com/design_pattern/filter_pattern.htm
Я работаю над программным обеспечением, очень похожим на Adobe Lightroom или ACDSee, но с другими целями. Пользователь (фотограф) может импортировать тысячи изображений со своего жесткого диска (было бы странно иметь более 100k / 200k изображений).
У нас есть боковая панель, где пользователи могут создавать собственные «фильтры», такие выражения как:
Does contain the keyword: "car"AND
Does not contain the keyword "woods"AND
(
Camera model is "Nikon D300s"OR
Camera model is "Canon 7D Mark II")
AND
NOT
Directory is "C:\today_pictures"Вы можете получить идею из приведенного выше примера.
У нас есть база данных SQLite, где хранится вся информация об изображениях. Вопрос в том, должны ли мы загружать ВСЕ объекты Photo в память из базы данных при первой загрузке программы и реализовывать шаблон проектирования Criteria / Filter, как описано на приведенном выше веб-сайте, поэтому наши классы Criteria фильтруют объекты или лучше выполнять критерии классы на самом деле генерируют SQL-запрос, который в итоге выполняется, чтобы извлечь из базы данных только то, что нужно?
Мы разрабатываем программу на C ++ (QT).
Решение
TL; DR: Это уже правильно реализовано в SQLITE3, и посмотрите, сколько времени это заняло. Вы столкнетесь с таким же бременем.
Это был бы ужасный случай дублирования данных, чтобы прочитать данные из базы данных и снова сохранить их в другой структуре данных. Используйте запросы к базе данных для реализации запроса, который вам дал пользователь. Позвольте базе данных выполнить запрос. Вот для чего нужны базы данных.
Реализовав систему поиска / запроса для ~ 500 тыс. Записей, вы сами будете переписывать большие куски стандартной базы данных. Это было бы в основном бессмысленное упражнение. SQLITE3 — это очень хорошо проверено и по существу надежно. Вам потребуется тысячи часов работы, чтобы реализовать даже небольшую часть своих возможностей. а также надежности / отказоустойчивости. Если это не кричит «изобретать велосипед», я не знаю, что делает.
База данных также позволяет очень легко реализовывать прогноз / выпадающие списки, чтобы помочь пользователю в написании запроса. Например, когда вы печатаете «модель камеры», пользователь может выбрать вариант автозаполнения или раскрывающийся список, чтобы выбрать одну или несколько моделей.
Вы заплатили «цену» за базу данных, было бы стыдно за все это потерять. Итак, используйте это. Это даст вам множество рычагов и позволит реализовать функции на два порядка быстрее, чем в противном случае.
Шаблон, с которым вы связаны, — это просто шаблон. Это не означает, что это точный план того, как спроектировать ваше приложение для работы с реальными данными. В конечном итоге вы будете бороться с такими вещами, как параллелизм (поток сканирования файлов, выполняющий обновление метаданных), индексация, отказоустойчивость перед лицом сбоев и т. Д. В итоге вы получите большие куски SQLITE, переопределенные для вашего конкретное применение. 500к записей метаданных — это не много, если вы хорошо спроектируете свой переводчик запросов и поддерживаете его с правильными индексами, он будет работать отлично.
Другие решения