【问题标题】:Deep path query using wildcard as a path使用通配符作为路径的深度路径查询
【发布时间】:2017-03-30 01:34:13
【问题描述】:

我有一些数据,我在其中尝试遵循 Firebase 关于扁平结构的建议,因此我的需求不会超出我的需要。最终结果是我在这样的节点中组织了引号:

quotes -> clientName -> quoteObject

quoteObjects 有一个“dateCreated”值,我希望能够像这样提取这些数据(因为当我为特定页面提取所有引号的一个大列表时,我然后使用对象分配来制作要显示的一大堆对象):

  const quotesRef = firebase.database().ref('quotes');
    quotesRef.orderByChild('dateCreated').on('value', snapshot => {
       // function
    });

不幸的是,dateCreated 值的深度超过了一级,因此标准查询不起作用。我知道如果您知道父路径,您可以进行深度路径查询,但在我的情况下,clientName 父级始终是唯一的。鉴于此,是否可以指定一种通配符路径?如果是这样,我会怎么做?干杯!

编辑:显示数据库示例,抱歉最初应该更具体。

quotes
    - ClientEmailOne
        -UniqueQuoteID
            - createdBy: ClientEmailOne
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
    - ClientEmailTwo
        -UniqueQuoteID
            - createdBy: ClientEmailTwo
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
     - ClientEmailThree
         -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
        -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
        -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"

【问题讨论】:

    标签: javascript firebase firebase-realtime-database


    【解决方案1】:

    Firebase 会考虑您运行查询的位置的子级。您指定排序/过滤的子元素可以包含属性的路径,但它不能包含任何通配符。

    更新

    使用您的新数据结构,您似乎正在尝试查询所有客户端以及每个客户端的所有报价。那里有两个通配符(“所有客户端”和“所有引号”),Firebase 的查询模型不允许。

    您当前的模型允许查询特定客户的所有报价:

    ref.child("quotes").child("ClientEmailOne").orderByChild("dateCreated")
    

    如果您想查询所有客户的所有报价,您需要添加一个包含所有报价的数据结构(无论其客户如何):

    allquotes
        -UniqueQuoteID
            - createdBy: ClientEmailOne
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
        -UniqueQuoteID
            - createdBy: ClientEmailTwo
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
         -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
        -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
        -UniqueQuoteID
            - createdBy: ClientEmailThree
            - dateCreated: 1479255005172
            - email: "clientsEmail@example.com"
    

    然后就可以查询了:

    ref.child("allquotes").orderByChild("dateCreated")
    

    【讨论】:

    • 感谢弗兰克的快速反应!所以只是为了澄清抱歉,这是否意味着它应该已经按原样按该值排序(即使它嵌套了几层深)?或者这是不可能的?因为它回来时未分类。谢谢
    • Firebase只有可以通过嵌套的子级进行排序,前提是这些子级位于固定路径上。所以你可以订购ref.child("quotes").orderByChild("property/under/clientName"),但不能订购ref.child("quotes").orderByChild("property/???/clientName")
    • 好的,感谢您的澄清。因此,鉴于 Firebase 建议以这种方式构建数据,例如在具有各种 id 键的单独节点下,他们又如何建议以这种方式查询?这似乎是一件很常见、很简单的事情?还是假设您只是按原样提取数据并自行排序?
    • 这很有帮助(发布问题时,请始终给出实际代码和数据的最小 sn-p。描述它永远不如实际代码/数据有效)。我根据你的数据更新了我的答案。
    • 使用 NoSQL 数据库时,您会不断发现“需要”复制数据的案例。对于大多数(面向 SQL 的)开发人员来说,这很常见,但不自然。您越早克服我们所有人对复制数据的自然焦虑,您就可以越早开始获得高度可扩展读取的好处。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-07-17
    • 1970-01-01
    相关资源
    最近更新 更多