Правильная реализация шаблона проектирования фильтра (критерия)

Шаблон проектирования объясняется здесь: 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, где хранится вся информация об изображении. Вопрос в том, должны ли мы загрузить все Фотообъекты в память из базы данных при первой загрузке программы и реализовать шаблон проектирования критериев/фильтров, как описано на веб-сайте, приведенном выше, чтобы наши классы критериев фильтровали объекты, или лучше сделать классы критериев фактически генерировать SQL-запрос, который в конечном итоге выполняется для того, чтобы получить только то, что необходимо из базы данных. база данных?

Мы разрабатываем программу на языке C++ (QT).

1 2
c++ sqlite design-patterns qt design-principles

1 ответ:

TL; DR: это уже правильно реализовано в SQLITE3, и посмотрите, сколько времени это заняло. Тебе предстоит та же ноша.

Это был бы ужасный случай дублирования данных, чтобы прочитать данные из базы данных и сохранить их снова в другой структуре данных. Используйте запросы к базе данных для реализации запроса, заданного пользователем. Пусть база данных выполнит запрос. Для этого и существуют базы данных.

Переопределяя систему поиска / запросов для записей ~500k, вы будете переписывать большие куски Болотной стандартной базы данных сами по себе. Это было бы в основном бессмысленное упражнение. SQLITE3 Очень хорошо протестирован и, по существу, надежен. Это будет стоить вам тысячи часов работы, чтобы переопределить даже небольшую часть его возможностей и надежность/отказоустойчивость. Если это не кричит "изобретение колеса", я не знаю, что делает.

База данных также позволяет очень легко реализовать lookahead / dropdowns, чтобы помочь пользователю в написании запроса. Например, как вы печатаете "модель камеры есть", пользователь может иметь возможность автозавершения или выпадающего списка, чтобы выбрать одну или несколько моделей.

Вы заплатили "цену" за базу данных,было бы обидно, если бы все это пропало. Так что используй его. Это даст вам много рычагов и позволит реализовать функции на два порядка быстрее, чем в противном случае.

Шаблон, с которым вы связались, - это просто шаблон. Это не означает, что это точная схема того, как проектировать ваше приложение для выполнения на реальных данных. В конечном итоге вы будете бороться с такими вещами, как параллелизм (поток сканирования файлов, выполняющийся для обновления метаданных), индексирование, отказоустойчивость перед лицом сбоев и т. д. В конце концов вы получите большие куски SQLITE, реимплементированные для вашего конкретного приложения. 500k записей метаданных-это ничего особенного, если вы хорошо спроектируете свой переводчик запросов и поддержите его соответствующими индексами, он будет работать отлично.

2