优化的查询数据模式

最简单、最快速的数据查询模式是:

  1. 单个表或视图
  2. 在服务器上根据需要进行预筛选
  3. 为预期查询正确索引列

在设计应用时,您需要考虑如何快速查询数据。 查询数据的更好方法是使用包含所需所有信息的单个表或视图,并在应用中显示它之前在服务器上进行筛选。 您还需要确保正确索引用于筛选或排序数据的列。 这使您的应用更快速、更流畅。

例如,假设您有一个显示客户及其销售员列表的库。 如果您将客户和销售员信息存储在单独的表中,则需要使用查找来获取每个客户的销售员姓名。 这会减慢您的应用速度,因为它需要对另一个表运行许多查询。 更好的方法是创建一个将客户和销售员信息合并在一个表中的视图,并将该视图用作库的数据源。 然后,您的应用只需运行一个查询即可获取所需的所有数据。

查询速度和数据规范化之间需要权衡。 数据规范化意味着您只存储数据一次,并避免重复。 这有助于保持数据的一致性和准确性。 但是,有时您需要复制一些数据以使查询更快速且更简单。 您需要在应用设计和表结构中平衡这两个目标。 否则,您的应用将变得缓慢且滞后,因为它需要执行大量工作来筛选和联接来自不同表的数据。

使用服务器端视图

视图可能是帮助平衡这些目标的最常用工具。 它们为查询提供单个表结构,针对查询中所需的内容预筛选数据,并启用与其他表的查找和联接。 因为在服务器上计算视图的筛选、查找和联接,因此有效负载和客户端计算都将最大限度地降低。

库可以显示数据源中的许多记录。 但有时,您需要显示来自与原始数据源相关的另一个数据源的附加信息。 例如,您有一个显示客户列表的库,并且想要显示分配给每个客户的销售员姓名。 销售员姓名与客户信息存储在不同的数据源中。 若要显示销售员的姓名,您需要使用查找函数在其他数据源中查找匹配的记录。 这将使用查找值展开原始表。

但是,如果您有许多记录和许多查找,则展开表可能会非常慢。 对于库中的每条记录,应用需要对其他数据源运行单独的查询并获取查找值。 这意味着应用可能需要对每条记录运行许多查询,这可能需要很长时间并影响应用性能。 这种反模式有时称为“N 平方 (n^2)”或“N+1”问题。

使用 StartsWith 或 Filter

Power Fx 提供多种搜索数据的方法。 一般来说,使用利用索引的表达式,例如 StartsWithFilter,而不是读取整个表的表达式,例如 In。 In 运算符适用于内存中集合或者外部数据源表非常小的情况。

考虑复制数据

有时,在查询中访问数据的速度很慢,因为它存储在不同的位置或采用不同格式。 为了使查询更快,您可以复制较慢的数据并将其本地存储在快速且易于查询的表中。 但是,这意味着本地数据可能不是原始数据的最新版本。 然后,运行另一个流程以定期更新本地数据。 此流程可以是 Power Automate 流、插件、存储过程或可将数据从一个位置移动到另一个位置的方法。

更新本地数据的频率要求取决于您的业务需要。 您的应用需要多新版本的数据? 例如,假设您在 Contoso(一家销售自行车的公司)工作。 可用自行车列表存储在产品数据库中,您可以通过自定义连接器中的 API 访问该数据库。 但是假设 API 调用很慢,因此您决定复制产品数据并将其本地存储在表中。 然后,您创建一个视图,将表与应用的其他相关数据合并在一起。 您还创建一个 Power Automate 流,该流每天运行并使用来自 API 的最新产品数据更新您的表。 然后,您的应用可以更快地查询本地数据,并且最多只有一天的历史数据。

复制数据是企业级应用程序中确保良好性能的一种常见技术。 您可以使用 Dataverse 插件、存储过程或数据移动将数据复制到针对查询进行优化的单个表中。 关键问题是:此数据必须是最新的吗? 如果您可以承受一些延迟,可以使用此技术来加快您的应用速度。

建议

若要实现此目标,请考虑以下问题和建议:

  1. 对于客户来说,查看库或数据网格中的数据价值有多重要? 首先选择一条记录,然后以表格形式显示数据,这是可以接受的吗?
  2. 视图是否可以执行必要的准备工作以采用正确的格式查看数据?
  3. 是否将使用“StartsWith”起作用的“IN”运算符?
  4. 您的数据需要有多新? 是否有一种数据复制战略可用于让您的查询默认在单个表上工作?