用小东西查询数据库,或者存储一些“更大的块”结果并在代码中过滤它们

本文关键字:结果 更大的块 代码 过滤 数据库 查询 小东西 或者 存储 | 更新日期: 2023-09-27 18:37:10

>我正在开发一个导入视频文件的应用程序,并允许用户根据各种条件浏览和过滤它们。通过导入,我的意思是创建我的VideoFile模型类的实例并将它们存储在数据库表中。一旦有数百个文件,用户就想浏览它们。

现在,他们在 UI 中的第一个选择是选择一个DateRecorded,这将在我的数据访问类上调用GetFilesByDate(Date date)方法。此方法将查询 SQL 数据库,仅请求具有给定日期的文件。

最重要的是,我需要按 FrameRateResolutionUserRating 来过滤文件。这将对已按日期过滤的文件设置其他条件。我正在决定走哪条路:

  1. 仅在所需DateRecorded更改时向数据库查询一组新文件。在 C# 代码中手动处理所有后续筛选,方法是循环访问存储的_filesForSelectedDay集合并根据当前的附加规则对其进行测试。
  2. 每次更改任何小过滤器时查询数据库,更频繁地请求一组更小且非常具体的文件。

你会选择哪一个,甚至更好,对其中任何一个的利弊有什么想法?

一些补充要点:

  • GetFilesByDate 中的查询应返回数十个项目,因此将结果存储在始终位于内存中的集合中并不是很昂贵。
  • 稍后,我可能不仅希望选择特定日期的文件,还希望选择整个月的文件。这可能会提供数百或数千个项目。这实际上使我倾向于选项二。
  • 数据访问层尚未实现。我只有一个实现所需接口的虚拟类,但将数据存储在内存集合中,而不是使用任何类型的数据库。
  • 一旦我到了那里,我几乎肯定会使用 SQLite 并将数据库存储在本地文件中。

用小东西查询数据库,或者存储一些“更大的块”结果并在代码中过滤它们

就我个人而言,我每次都会去数据库,直到它被证明不切实际。 如果是少量数据,则开销也应该很小。 当它变大时,数据库就会发挥作用。 您不太可能编写比数据库更好的代码,尽管往返可能会花费。 使用数据库,您的数据将始终保持一致且最新。

如果您发现对BD的打击太大,则可以尝试缓存数据并确定是否已经请求了部分或全部数据以节省时间。 但是,您需要处理老化和一致性问题。 然后,您还拥有内存塞满数据可用于其他事情的服务器!

基本上,在它成为一个问题之前,只需使用数据库并将您的精力用于您遇到的实际问题,而不是可能的问题。

如果您已经获得了一堆数据,则无需再次查询数据库以获取集合的子集。只需将其存储在一个对象中,您就可以在用户优化搜索查询时查询该对象。