嵌套的FutureBuilder与嵌套调用以从数据库进行延迟加载 [英] Nested FutureBuilder vs nested calls for lazy loading from database

查看:153
本文介绍了嵌套的FutureBuilder与嵌套调用以从数据库进行延迟加载的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要在可以遵循的两种方法之间选择最佳方法。

I need to choose best approach between two approaches that I can follow.

我有一个Flutter应用程序,该应用程序使用 sqflite 以保存数据,在数据库内部,我有两个表:

I have a Flutter app that use sqflite to save data, inside the database I have two tables:

雇员:

+-------------+-----------------+------+
| employee_id | employee_name   |dep_id|
+-------------+-----------------+------+
|     e12     | Ada Lovelace    | dep1 |
+-------------+-----------------+------+
|     e22     | Albert Einstein | dep2 |
+-------------+-----------------+------+
|     e82     | Grace Hopper    | dep3 |
+-------------+-----------------+------+

SQL:

CREATE TABLE Employee(
    employee_id TEXT NOT NULL PRIMARY KEY,
    employee_name TEXT NOT NULL ,
    dep_id TEXT,
    FOREIGN KEY(dep_id) REFERENCES Department(dep_id)
    ON DELETE SET NULL
);

部门:

+--------+-----------+-------+
| dep_id | dep_title |dep_num|
+--------+-----------+-------+
| dep1   | Math      | dep1  |
+--------+-----------+-------+
| dep2   | Physics   | dep2  |
+--------+-----------+-------+
| dep3   | Computer  | dep3  |
+--------+-----------+-------+

SQL:

CREATE TABLE Department(
    dep_id TEXT NOT NULL PRIMARY KEY,
    dep_title TEXT NOT NULL ,
    dep_num INTEGER,
);

我需要显示部门的 ListGrid 存储在 Employee 表中的文件。我应该查看 Employee 表并从中获取部门ID,这很容易,但是在获取 dep_id 之后,我需要使用这些ID制作一张卡因此我需要部门表中的信息。我从 Emplyee 表中获取的那些ID的
完整信息位于部门表中。

I need to show a ListGrid of departments that are stored in the Employee table. I should look at Employee table and fetch department id from it, This is easy but after fetching that dep_id I need to make a card from those ids so I need information from Department table. complete inforamtion for thoses id I had fetched from Emplyee table is inside Department table.


每个表中都有成千上万的行。

There are thousands of rows in each table.

我有一个数据库帮助程序类可以连接到数据库:

I have a database helper class to connect to the database :

DbHelper 是这样的:

Future<List<String>> getDepartmentIds() async{
    'fetch all dep_id from Employee table'
}

Future<Department> getDepartment(String id) async{
    'fetch Department from Department table for a specific id'
}

Future<List<Department>> getEmployeeDepartments() async{
    '''1.fetch all dep_id from Employee table
    2.for each id fetch Department records from Department table'''

    var ids = await getDepartmentIds();
    List<Departments> deps=[];
    ids.forEach((map) async {
        deps.add(await getDepartment(map['dep_id']));
      });
}

有两种方法:


  1. 在dbhelper中定义一个函数,该函数返回所有 dep_id Employee 表中的c $ c>( getDepartmentIds 和另一个返回该特定ID的部门对象(模型)的函数。( getDepartment

  1. Define a function in dbhelper that returns all dep_id from Employee table(getDepartmentIds and another function that returns a department object(model) for that specific id.(getDepartment)

现在我彼此之间需要两个 FutureBuilder ,一个用于获取ID,另一个用于获取部门模型。

Now I need two FutureBuilder inside each other, one for fetching ids and the other one for fetching department model.





second One:


  1. 定义一个函数,该函数首先获取id,然后在该函数内部将每个id映射到部门模型。( getEmployeeDepartments

  2. 所以我需要一个 FutureBuilder

  1. Define a function that first fetch ids then inside that function each id is maped to department model.(getEmployeeDepartments)
  2. So I need one FutureBuilder .

哪个更好?
是我应该让FutureBuilders处理它还是对 dbHelper 施加压力以使其受阻?

Which one is better?? should I let FutureBuilders handle it or I should put pressure on dbHelper to habdle it?

如果我使用第一个Appr然后,我不得不(据我所能想像!)把第二个以后的调用(根据其id( getDepartment <来获取部门对象(模型)的那个) / code>))上的 build 函数,建议不要这样做。

If I use the first approach then I have to(as far as I can imagine!) put the the second future call(the one that fetch Department Object(model) based on it's id(getDepartment)) on build function and it's recommended no to do so.

第二个是它在 dbHelper 中做了很多嵌套调用。

And the problem with second one is that it does a lot of nested call in dbHelper.

我使用了 ListView.builder 来提高性能。

我检查了两个数据,但不知道哪个更好。我猜这取决于flutter和sqlite(sqflite)。

I checked both with some data but couldn't figure out which one is better. I guess it depends both on flutter and sqlite(sqflite).

哪个更好?还是有更好的方法?

which one is better or is there any better approach?

推荐答案

鉴于我在此示例中看不到太多代码,因此我将对您的问题做一个高级解答。

Given that I don't see too much code on this example, I'll do a high-level answer on your questions.

评估一种方法


  1. 这部分坚持到底:全部返回

  2. 我想说一句,因为全部归还通常都不是一个好的解决方案,尤其是因为您提到表中有很多行。

评估方法二


  1. 我不确定与第一种方法相比在性能上有何不同,出于相同的原因,这似乎也很糟糕。我认为这只是改变您的UI逻辑而已。

典型的无尽列表方法


  1. 您将在 Employees 表上查询并加入部门 >表。

  2. 您将在UI上实现分页,并将值从第一步开始传递给查询。

  3. 从根本上讲,会需要这些变量:Take,Skip,HasMore

  4. Take:请求每个查询的项目数

  5. 跳过:下一个查询要跳过的项目数,这就是驱动用户界面的内存中当前列表中的项目数的大小。

  6. 有更多信息:您可以在每个查询的响应中进行设置,以使UI知道是否还有更多项目。

  7. 向下滚动列表,当到达底部时,您将请求更多项目。

  1. You would do a query on the Employees table with a join to the Departments table.
  2. You would implement Pagination on your UI and pass in your values to the query from step one.
  3. At a basic level you'll need these variables: Take, Skip, HasMore
  4. Take: The count # of items to request each query
  5. Skip: The count # of items to skip on the next query, this will be the size of the number of items you currently have in your List in memory driving your UI.
  6. HasMore: You can set this on the response of each query, to let the UI know if there are still more items or not.
  7. As you scroll down the list, when you get to the bottom, you will request more items .

发出一个查询,例如:Take:10,Skip:0
当您到达用户界面底部时,下一个查询:Take:10,Skip:10
等等。

Initially issue a query for example: Take: 10, Skip: 0 Next query when you hit the bottom of the UI: Take: 10, Skip: 10 etc..

示例SQL查询:

SELECT * 
FROM Employees E
   JOIN Departments D on D.id = E.dept_id
order by E.employee_name  
offset {SKIP#} rows
FETCH NEXT {TAKE#} rows only

希望这会有所帮助,我不确定您实际上要执行的操作-就代码而言。

Hopefully, this helps, I'm not fully sure what you're trying to do actually - in terms of Code.

这篇关于嵌套的FutureBuilder与嵌套调用以从数据库进行延迟加载的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆