用基於光標的分頁登錄實時數據

分頁是一種將大型記錄集分解為稱為頁面的較小部分的技術。作為開發人員，您應該熟悉實施分頁，但是即使對於經驗豐富的開發人員來說，為實時數據實施分頁可能會變得棘手。在本教程中，我們將討論實時數據分頁和基於光標的分頁的實際用例和解決方案。

鑰匙要點

分頁是一種用於將大記錄集分為較小的部分（稱為頁面）的方法。由於頻繁更新，在添加或刪除數據時實施分頁可能會具有挑戰性。

>

>各種社交網站，例如Twitter和Facebook，已成功實施了實時數據分頁。他們使用基於光標的分頁，該分頁依賴於唯一的標識符（光標），而不是分頁的記錄計數。 基於光標的分頁需要至少一個具有唯一順序值的列，類似於Twitter的MAX_ID參數或參數後的Facebook。它還需要一個計數參數來過濾有限數量的結果，以及下一個和上一個URL才能瀏覽數據。 基於光標的分頁通常比基於偏移的分頁更有效，更可靠，尤其是用於實時數據或大型數據集。它減少了服務器上的負載，並使分頁過程更快，更高效。
• >
>實現基於光標的分頁涉及幾個步驟，包括確定用作光標的唯一標識符，修改數據庫查詢以基於此光標獲取記錄，並更新應用程序的UI以處理流行的數據並允許用戶來處理用戶瀏覽頁面。
• 實時數據分頁
中識別問題 Wikipedia將實時數據定義為收集後立即提供的信息。提供的信息的及時性沒有延遲。 在這樣的應用程序中，由於頻繁更新，很難提供準確的分頁數據。讓我們看一下在管理實時數據時使用標準分頁的問題。
• >
• >
假定數據是靜態的，並且不經常變化 - 在默認分頁中，檢索到的記錄集被分為許多頁面。由於數據並不經常更改，用戶覺得分頁正常工作，但是在添加新數據或刪除現有數據時，分頁的結果變得不准確。

>

>

分頁僅考慮記錄計數，而不是每個單獨的記錄 - 記錄使用總記錄計數分為頁面，並正常分頁。它沒有考慮每個記錄是否屬於分頁上的正確頁面。這可以導致記錄的多餘顯示。

>

考慮到這些要點，很難用來默認分頁技術來處理實時數據。讓我們嘗試使用實際情況來識別問題。

假設我們最初有20個記錄，並且我們使用10個記錄作為將記錄分解為頁面的極限。下圖顯示瞭如何將記錄分成頁面。

>

>現在假設在我們在第一頁上時，結果集由五個新記錄更新。下圖顯示了當前方案。

>現在我們導航到第二頁。根據我們的第一張圖像，它應從1-10中檢索記錄。但是，將檢索具有數字15-6的記錄。您可以清楚地看到，第一頁以及第二頁都顯示了記錄數字15-11。

實時數據分頁的實際用例

我們都知道，重新發明車輪不是開發人員應該做的。我們應該研究在考慮建立自己的問題之前解決這些問題的現有網頁技術。許多社交網站（例如Twitter和Facebook）在其用戶配置文件中提供了實時數據。在本節中，我們將使用一些最受歡迎的網站來研究實時數據分頁的實際用例。

> Twitter API光標的分頁

Twitter用戶配置文件經常用新的推文填充，因此Twitter時間行數據檢索機制應該是實時數據供稿中識別分頁技術的良好開始。讓我們看看它是如何使用Twitter API方法的工作方式的。

以下內容包含對Twitter API搜索推文方法的示例請求。

在上述URL中，我們請求包含“ PHP”一詞的最新推文，並使用計數參數將結果設置為10塊。這是偏移分頁的典型行為，我們根據記錄計數回复。但是在這裡，我們可以看到兩個距離ind_id和max_id的其他參數，這使基於光標的分頁構成。讓我們來看看基於光標的分頁如何使用我們的早期示例。

>

>我們將20個記錄分為2頁，並假設我們在第一頁上。 5個新記錄被添加到列表的頂部。以下圖像預覽了當前方案。

https://api.twitter.com/1.1/search/tweets.json?q=php&since_id=24012619984051000&max_id=250126199840518145&result_type=recent&count=10

現在，讓我們看一下Twitter搜索請求的第一頁生成的響應的一部分。您可以在此處查看完整的響應格式。

https://api.twitter.com/1.1/search/tweets.json?q=php&since_id=24012619984051000&max_id=250126199840518145&result_type=recent&count=10

如您所見，

> search_metadata部分提供了有關結果的詳細信息。如果有更多記錄可以分頁，它將生成Next_Results URL。我們主要使用max_id參數進行分頁。對於每個響應，我們將檢索max_id參數，我們可以使用它來生成下一個結果集。我們使用MAX_ID參數接收比給定ID的更古老的結果。

>

在我們的示例中，在顯示記錄20-11時，我們應該將MAX_ID參數作為記錄11檢索。然後，我們將MAX_ID傳遞以生成下一個結果集。因此，我們將獲得準確的結果，如下圖所示。

。

如您所見，我們可以通過消除頂部15個記錄而不是基於偏移的分頁上的15個記錄來獲得第二頁的準確結果。在基於光標的分頁中，我們無法考慮頁面的概念，因為它會迅速變化，因此結果將被視為上一個或下一個。通常，MAX_ID足夠有效地產生準確的結果，但是在某些情況下，自_ID以來也是必不可少的，而來回訪問。您可以查看在Twitter的開發人員部分上同時使用MAX_ID和afta後的_ID的更高級的示例。

基於Facebook API光標的分頁

> 與Twitter相比，Facebook的API實現略有不同，即使兩個API都使用相同的理論。讓我們看一下示例Facebook API請求的響應。

>

如您所見，Facebook使用兩個基於字符串的光標，以進行分頁，而不是aft_id and max_id。在Facebook中，前光標將指向頁面的開始，而後光標指向頁面末尾。

大多數API具有實時數據使用此機制，可以通過其結果準確地劃分。作為開發人員，我們需要了解基於光標的分頁背後的理論，以便使用現有的API並在必要時創建自己的理論。

"search_metadata": {
  "max_id": 250126199840518145,
  "since_id": 24012619984051000,
  "refresh_url": "?since_id=250126199840518145&q=php&result_type=recent&include_entities=1",

  "next_results": "?max_id=249279667666817023&q=php&count=10&include_entities=1&result_type=recent",

  "count": 10,
  "completed_in": 0.035,
  "since_id_str": "24012619984051000",
  "query": "php",
  "max_id_str": "250126199840518145"
}

實時數據建立分頁的基礎

實施實時數據分頁是本教程範圍之外的複雜任務，因此我們將研究基本需求和創建簡單的分頁機制以了解基於光標的分頁的過程。

讓我們使用先前討論的示例來確定基於光標的分頁的基本組成部分。

。

光標 - 我們需要至少具有一個具有唯一順序值的列來實現基於光標的分頁。這可能類似於Twitter的MAX_ID參數或參數後的Facebook。

計數 - 我們需要計數參數，就像基於偏移的分頁一樣，在光標之前或之後過濾有限數量的結果。
• >

  下一個URL - 如果我們通過API提供分頁，則需要。用戶需要知道下一頁是否可用以及如何獲取下一個數據集。

上一個URL - 如果我們通過API提供分頁，則需要。用戶需要知道上一頁是否可用以及如何獲取下一個數據集。

• 這些是基於光標的分頁的基本需求。開發人員經常與基於偏移的分頁合作，很少有機會與基於光標的分頁合作，因此在適當的情況下確定每種技術的差異和好處很重要。

  >>>>>>
在偏移分頁中，我們可以按任何列進行排序並分配結果，而基於光標的分頁則取決於唯一光標列的分類。

偏移分頁還包含頁碼，除了下一個鏈接和上一個鏈接。但是由於數據的高度動態性質，我們無法為基於光標的分頁提供頁碼。

通常，偏移分頁允許我們在兩個方向上導航，而基於光標的分頁大多用於向前導航。
• 到目前為止，我們研究了基於光標的分頁的基本需求和差異。現在，我們可以進入示例實現以確定其工作原理。

  實現基於光標的分頁

• 首先，我們使用PDO創建數據庫連接。然後，我們執行句柄匯輪函數來插入結果。 然後，我們檢查MAX_ID或MIN_ID參數是否可在URL中使用。 MAX_ID與Facebook的參數相似，並用於向前導航。 MIN_ID與Facebook的參數相似，並用於向後導航。另外，我們設置了導航方向，使用max_id或min_id和分類順序的Where子句。
  > 然後，我們執行查詢以獲取完整的結果計數，然後進行相同的查詢，並帶有限制性語句以縮小結果。
>
• 如果我們朝著先前的方向進行遍歷，則必須將排序更改為ASC。否則，它將檢索最新記錄，而不是上一頁。我們扭轉了數組中的記錄以顯示它們為下降。 然後，我們循環通過結果。循環時，我們將第一個記錄的ID分配為MIN_ID，最後記錄為MAX_ID。這些光標值用於通過消除重複來過濾準確的數據。 最後，我們可以查看用於實現分頁鏈接的Paginator函數。

以下代碼包含本節中生成的分頁的初始化代碼。

https://api.twitter.com/1.1/search/tweets.json?q=php&since_id=24012619984051000&max_id=250126199840518145&result_type=recent&count=10

>現在我們有了一個簡單的數據分頁示例，以了解實時數據分頁的工作方式。使用此代碼並通過結果分頁。在登機時，在表末尾添加一些記錄以實時。然後向後和向後鋪設以檢查頁面中的數據重複。在基於偏移的分頁上做同樣的事情以了解差異。

結論

在本教程中，我們通過基於光標的分頁了解了實時數據分頁背後的理論。讓我們在下面的評論中知道您的想法和經驗！ 基於光標的分頁

的常見問題（常見問題解答）

>基於偏移量和基於光標的分頁之間的主要區別是什麼？

基於偏移的分頁涉及從一開始就跳過一定數量的記錄，然後獲取設定的記錄。但是，如果在分頁上添加或刪除了數據，此方法可能會導致重複記錄等問題。另一方面，基於光標的分頁使用從最後一個獲取的記錄中使用唯一的標識符（光標）來檢索下一組記錄。此方法更有效，避免了與基於偏移的分頁相關的問題，使其非常適合實時數據。

>

>基於光標的分頁如何處理實時數據？基於基於的分頁對於實時數據特別有效，因為它使用了最後一個獲取的記錄中使用唯一的標識符（光標）來檢索下一組記錄。這意味著，即使添加了新數據或在分頁過程中刪除了現有數據，光標仍將指向正確的下一個記錄，以確保不會錯過或重複記錄。可以與任何類型的數據一起使用？但是，對於效率至關重要的實時數據或大型數據集特別有效。光標可以是任何唯一的標識符，例如時間戳或唯一的ID，可用於獲取下一組記錄。

>基於光標的分頁如何改善性能？基於光標的分頁通過減少需要立即處理的數據量來提高性能。基於光標的分頁只能獲取所有記錄，而是跳過一定數字，而只能根據光標獲取下一組記錄。這樣可以減少服務器上的負載，並使分頁過程更快，更高效。

>

>如何在我的應用程序中實現基於光標的分頁？首先，您需要確定用作光標的唯一標識符。這可能是時間戳，獨特的ID或任何其他獨特的值。接下來，您需要修改數據庫查詢以根據此光標獲取記錄。最後，您需要更新應用程序的UI來處理分頁的數據並允許用戶在頁面上導航。

基於Cursor的基於Cursor的分頁的潛在缺陷是什麼？分頁比基於偏移的分頁更有效和可靠，它確實具有一些潛在的缺點。例如，實施可能更複雜，尤其是如果您的數據沒有明確的唯一標識符作為光標。此外，它可能不適用於所有用例，例如當您需要跳到特定的頁碼時。

>可以將基於光標的分頁用於GraphQl？

是的，是的，Cursor基於GraphQl可以使用基於基礎的分頁。實際上，GraphQL通過中繼規範對基於光標的分頁有內置支持。這使您可以輕鬆地在GraphQl應用程序中實現高效，可靠的分頁。

>

>基於光標的分頁如何使用MySQL？標識符，例如時間戳或獨特的ID，作為光標。然後，您可以使用“ where”和“ limit”子句來修改SQL查詢以根據此光標獲取記錄，以指定以獲取的記錄範圍。

>如何在其中使用Slack Slack使用基於光標的分頁。 API？

Slack在其API中使用基於光標的分頁有效獲取大量數據。他們使用唯一的標識符作為光標，並在API響應中提供此光標，以允許客戶端獲取下一組記錄。這使他們可以處理具有高性能和可靠性的大型數據集。

>基於光標的分頁的JSON API規範是什麼？標識符是光標，並將此光標包括在API響應的“鏈接”對像中。這使客戶可以通過遵循提供的鏈接輕鬆獲取下一組記錄。該規範提供了一種在JSON API中實現基於光標的分頁的標準，一致的方法。

以上是用基於光標的分頁登錄實時數據的詳細內容。更多資訊請關注PHP中文網其他相關文章！