2017-03-06 118 views
0

這裏是我的火力地堡數據結構:火力地堡數據庫訪問多個記錄

{ 
    "companies": { 
    "-Ke_b8p6OBaz1VCeovAH": { 
     "display_name": "First User's Company", 
     "users": { 
     "ir7jjLPA3fXCVsdc4OzzSiH9RJd2": "admin" 
     } 
    }, 
    "-Ke_cmhDaIeGJjFwsDI1": { 
     "display_name": "First User's Second Company", 
     "users": { 
     "ir7jjLPA3fXCVsdc4OzzSiH9RJd2": "admin" 
     } 
    }, 
    "-Ke_b9OgwY2IBdj5szmJ": { 
     "display_name": "Second User's Company", 
     "users": { 
     "5XcpmN7DgEWNnmWZucyQiOh4TJt2": "admin" 
     } 
    } 
    }, 

    "users": { 
    "ir7jjLPA3fXCVsdc4OzzSiH9RJd2": { 
     "display_name": "First User" 
    }, 
    "5XcpmN7DgEWNnmWZucyQiOh4TJt2": { 
     "display_name": "Second User" 
    } 
    } 
} 

我試圖做此數據的查詢(通過REST例如):

example.firebase.com/companies.json?orderBy="users/ir7jjLPA3fXCVsdc4OzzSiH9RJd2" 

我希望返回

{ 
    "-Ke_b8p6OBaz1VCeovAH": { 
    "display_name": "First User's Company", 
    "users": { 
     "ir7jjLPA3fXCVsdc4OzzSiH9RJd2": "admin" 
    } 
    }, 
    "-Ke_cmhDaIeGJjFwsDI1": { 
    "display_name": "First User's Second Company", 
    "users": { 
     "ir7jjLPA3fXCVsdc4OzzSiH9RJd2": "admin" 
    } 
    } 
} 

相反,我得到

{ 
    "error": "Index not defined, add \".indexOn\": \"users/ir7jjLPA3fXCVsdc4OzzSiH9RJd2\", for path \"/companies\", to the rules" 
} 

這裏是我的火力地堡安全規則

{ 
    "rules": { 
    ".read": true, 
    ".write": true, 

    // Companies 
    "companies": { 
     ".indexOn": ["display_name", "users"], 
    } 
    } 
} 

這是不可行的索引更新爲每個用戶的安全規則,所以我會怎麼處理呢?

回答

1

Firebase不支持您習慣使用的類過濾器中的「過濾」。根據您當前的數據結構,你要麼需要:

  1. 查詢所有公司和過濾器在你的目標用戶的客戶端,或
  2. 重塑你的用戶集合添加屬性,指示該公司的用戶是一個管理員。然後,您可以在一個查詢中獲取用戶記錄,然後在第二個時間查詢用戶是管理員的公司的記錄。

這些選項聽起來很可怕,但不管信不信,這就是Firebase被設計爲「快速」處理的情況。它彌補了大規模的代碼/查詢效率低下的問題,所以在使用它時,你需要忘記很多特定於SQL的最佳實踐,例如規範化數據,有效的查詢/連接操作等。儘管看起來像額外的工作,但如果您實際上對操作進行基準測試(特別是如果啓用持久性/緩存等選項時),即使採用這些額外步驟,也可以達到或超過SQL環境性能。可以將其看作RISC與CISC,其中RISC是Firebase,而CISC是SQL。

+2

「Firebase不支持任何類型的過濾/搜索。」這種說法在這方面似乎有誤導性。不是本身搜索,而是'orderBy' +'equalTo'是一個簡單的過濾器,適用於@ Cody的問題。我不熟悉REST API,但是對孩子的孩子進行排序,稱爲[deep querying](https://firebase.googleblog.com/2015/09/introducing-multi-location-updates-and_86.html ),在SDK中肯定是可行的。 –

+0

因爲Firebase文檔中有關於排序和過濾數據的整個部分,所以我確實會更改第一句話:https://firebase.google.com/docs/database/web/lists-of-data#sorting_and_filtering_data。 –

+0

@TravisChristian - 我讀過那篇文章,以及Frank發佈的一篇文章。但是,我無法查詢上面提到的方式。 隨着深入查詢他們的參考,密鑰總是相同的,即'高度','重量'等。 我正在查詢將改變的鍵。鍵是用戶uid。此外,將這些ID作爲密鑰存儲在字典中是Firebase數據庫中推薦的存儲實踐。 https://firebase.google.com/docs/database/web/structure-data#fanout –