如何在Firebase中構建數據以避免N + 1選擇？

由於Firebase安全規則不能用於過濾兒童，因此在基本多用戶應用程序中構建數據以實現高效查詢的最佳方式是什麼？我已經閱讀了幾個指南，但是在縮小給出的例子之後，它們似乎崩潰了。如何在Firebase中構建數據以避免N + 1選擇？

假設您有像WhatsApp這樣的基本消息應用程序。用戶可以與其他用戶組打開聊天，以在他們之間發送私人消息。這裏是我的這怎麼會在火力地堡（有點類似於this example從文檔）組織最初的想法：

{ 
    users: { 
     $uid: { 
      name: string, 
      chats: { 
       $chat_uid : true, 
       $chat2_uid: true 
      } 
     } 
    }, 
    chats: { 
     $uid: { 
      messages: { 
       message1: 'first message', 
       message2: 'another message' 
      } 
     } 
    } 
}

火力地堡的權限可以設置爲僅允許用戶閱讀chats被標記在他們的用戶對象true （並限制任意添加到chats對象等）。

但是，這種佈局需要N + 1個選擇用於幾種常見情況。例如：要構建主屏幕，應用程序必須先檢索用戶的chats對象，然後爲每個線程發出get請求以獲取其信息。如果用戶想要搜索特定字符串的會話，那麼同樣的事情：應用程序必須爲他們有權訪問的每個聊天單獨運行一個請求，以便查看它是否匹配。

我很想設置一個node.js服務器來針對chats樹運行根認證的查詢，並完全跳過客戶端的firebase代碼。但這首先打敗了Firebase的目的。

有沒有辦法使用Firebase權限來組織這樣的數據並避免N + 1選擇問題？

來源

2016-05-29 Andy Miller

對於幾乎每種情況，我都會發現同樣的問題，以至於我開始懷疑Firebase是否設計用於處理n + 1查詢，也許我們不應該擔心它。這篇[關於denormalising數據的官方博客文章]（https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html）似乎建議做n + 1（參見'Now您可以簡單地獲取任何給定鏈接的註釋列表並呈現它們：'），就像[firefeed.io示例應用程序]（https://firefeed.io/about.html）一樣，請參閱「應用程序邏輯」。 /不確定 –

似乎並不一定需要避免n + 1個查詢，並且Firebase是專門設計的，可以在執行n + 1次選擇時提供良好的性能，儘管對於來自關係數據庫背景的開發人員而言，它是反直覺的。

n的例子+在Firebase 2.4.2 documentation 1後面跟着一個令人欣慰的消息：

// List the names of all Mary's groups 
var ref = new Firebase("https://docs-examples.firebaseio.com/web/org"); 

// fetch a list of Mary's groups 
ref.child("users/mchen/groups").on('child_added', function(snapshot) { 
    // for each group, fetch the name and print it 
    String groupKey = snapshot.key(); 
    ref.child("groups/" + groupKey + "/name").once('value', function(snapshot) { 
    System.out.println("Mary is a member of this group: " + snapshot.val()); 
    }); 
});

是真的好嗎單獨查找每個記錄？是。 Firebase協議使用Web套接字，客戶端庫對傳入和傳出的請求進行了大量的內部優化。在我們獲得數萬條記錄之前，這種方法是完全合理的。事實上，下載數據所需的時間（即字節數）使連接開銷的任何其他問題都沒有了。

來源

2016-07-06 09:53:02

如何在Firebase中構建數據以避免N + 1選擇？

回答

相關問題