最佳化的查詢資料模式

最簡單、最快速的資料查詢模式是：

1. 單一表格或檢視表
2. 在伺服器上根據您的需求進行預先篩選
3. 資料行針對預期查詢正確建立索引

當您設計應用程式時，您需要考慮如何快速查詢資料。 查詢資料的最佳方法是使用包含您所需之全部資訊的單一表格或檢視表，並在將其顯示在應用程式之前，在伺服器上對其進行篩選。 您還需要確認用於篩選或排序資料的資料行已正確建立索引。 這使您的應用程式更快速、更流暢。

例如，假設您有一個顯示客戶及其銷售人員清單的資源庫。 如果您將客戶和銷售人員資訊儲存在分開的表格中，則需要使用查找來取得每個客戶的銷售人員姓名。 這會減慢您的應用程式速度，因為它需要對另一個表格執行許多查詢。 更好的方法是在一張表格中，建立一個將客戶和銷售人員資訊組合在一起的檢視表，並將該檢視表用作資源庫的資料來源。 然後您的應用程式只需執行一個查詢，就能取得所需的全部資料。

查詢速度和資料歸一化之間需要協調。 資料歸一化表示您只儲存資料一次，避免重複。 這有助於保持資料的一致性和準確性。 然而，有時您需要複製一些資料以使查詢更快、更容易。 您需要在應用程式設計和表格結構中平衡這兩個目標。 否則，您的應用程式將變得緩慢且遲滯，因為它需要執行大量工作來篩選和聯結來自不同表格的資料。

使用伺服器端檢視表

檢視表大概是幫助平衡這些目標時最常用的工具。 它們為查詢提供單一表格結構，針對查詢中所需的內容預先篩選資料，並啟用與其他表格的查找和聯結。 由於檢視表的篩選條件、查找和聯結是在伺服器上計算的，因此承載和用戶端計算都會被最小化。

避免在資源庫上進行過多查找

資源庫可以顯示資料來源中的許多記錄。 但有時，您需要顯示與原始資料來源相關的另一個資料來源的附加資訊。 例如，您有一個顯示客戶清單的資源庫，且您想要顯示指派給每個客戶的銷售人員的姓名。 銷售人員的姓名與客戶資訊儲存在不同的資料來源中。 若要顯示銷售人員的姓名，您需要使用查找功能在其他資料來源中尋找符合的記錄。 這將使用查找值展開原始表格。

但是，如果您有很多記錄和很多查找，則展開表格可能會非常慢。 對於資源庫中的每筆記錄，應用程式需要對其他資料來源執行單獨的查詢並取得查找值。 這代表應用程式可能需要對每筆記錄執行許多查詢，這可能需要很長時間且會影響應用程式效能。 這種反模式有時稱為「N 平方，(n^2)」或「N+1」問題。

使用 StartsWith 或篩選條件

Power Fx 提供數種搜尋資料的方法。 一般來說，使用利用索引的運算式，例如 StartsWith 或篩選條件，而不是像這樣讀取整張表格 In。 In 運算子適用於記憶體中集合或如果外部資料來源表格非常小。

考慮複製資料

有時，在查詢中存取資料的速度很慢，因為它儲存在不同的位置或格式。 為了讓查詢快一點，您可以複製緩慢的資料並將其儲存在本機，可以快速且易於查詢的表格中。 然而，這代表本機資料可能不是原始資料的最新版本。 然後執行另一個程序已定期更新本機資料。 這個程序可以是一個 Power Automate 流程、外掛程式、預存程序或任何其他可以將資料從一個地方移動到另一個地方的方法。

更新本機資料的頻率需求取決於您的業務需求。 應用程式的資料需要有多新？ 例如，假設您在 Contoso (一家銷售自行車的公司) 工作。 可用自行車清單儲存在產品資料庫中，您可以透過自訂連接器中的 API 存取資料庫。 但假設 API 呼叫很慢，因此您決定複製產品資料並將其儲存在本機表格中。 然後，您建立一個檢視表，將表格與應用程式的其他相關資料組合起來。 您還建立了一個 Power Automate 流程，會每天執行並使用來自 API 的最新產品資料更新您的表格。 然後您的應用程式就可以更快地查詢本機資料，且資料頂多是過了一天的資料。

複製資料是企業級應用程式中，確保良好效能的常見技術類型。 您可以使用 Dataverse 外掛程式、預存程序或資料移動，將資料複製到針對查詢進行最佳化的單一表格中。 關鍵問題是：這些資料需要多新？ 如果您可以接受一些延遲，則可以使用此技術來加速您的應用程式。

建議

若要實現這個目標，請考慮以下問題和建議：

1. 對於客戶來說，查看資源庫或資料格線中的資料值有多重要？ 可以接受先選取一筆記錄，再以表單方式顯示資料嗎？
2. 檢視表可以做必要的準備工作以用正確的格式檢視資料嗎？
3. 您是否使用「IN」運算子，其中「StartsWith」將起作用？
4. 您的資料需要有多新？ 是否存在一種資料複製原則，可以用來讓查詢預設在單一表格上工作？