这里解释了设计模式： http://www.tutorialspoint.com/design_pattern/filter_pattern.htm
我正在使用与Adobe Lightroom或ACDSee非常相似但具有不同用途的软件。用户（摄影师）能够从他的硬盘中导入数千张图像（拥有超过100k / 200k图像并不奇怪）。
我们有一个侧面板，用户可以在其中创建自定义＆＃34;过滤器＆＃34;这些表达式如下：
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）开发程序。
答案 0 :(得分：2)
TL; DR ：它已在SQLITE3中正确实现，并查看花了多长时间。你将面临同样的负担。
从数据库读取数据并将其再次存储在另一个数据结构中是一个可怕的数据重复案例。使用数据库查询来实现用户提供的查询。让数据库执行查询。这就是数据库的用途。
通过重新实现约500k记录的搜索/查询系统，您将自己重写一个沼泽标准数据库的大块。这绝不是毫无意义的运动。 SQLITE3 非常经过良好测试，基本上是万无一失的。它将花费您数千小时的工作来重新实现其和可靠性/弹性的一小部分功能。如果那不会尖叫＆＃34;重新发明轮子＆＃34;，我不知道是什么。
数据库还允许您非常轻松地实现前瞻/下拉，以帮助用户编写查询。例如，当您键入＆＃34;相机型号为＆＃34;时，用户可以选择自动完成或下拉菜单从中选择一个或多个模型。
你支付了＆＃34;价格＆＃34;对于一个数据库来说，浪费所有这一切都是一种耻辱。所以，使用它。它将为您提供大量的杠杆作用，并允许您实现比其他方式快两个数量级的功能。
您链接的模式只是一种模式。它并不意味着它是如何设计应用程序以对真实数据执行的确切蓝图。最终，你将会遇到诸如并发（运行以更新元数据的文件扫描线程），索引，崩溃面临的弹性等问题。最终，你最终会遇到很大的问题。 SQLITE为您的特定应用程序重新实现。 500k元数据记录并不算什么，如果你设计好你的查询翻译器并使用适当的索引支持它，它就能很好地工作。