如何在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选择？

回答

相关问题